U.Seung's Log

빌드(컴파일, 링크) 속도가 느리다면....

U_Seung — Thu, 04 Feb 2010 10:55:21 +0900

컴파일 속도가 느리다면.. IncrediBuild를 쓰세요.

링크 속도가 느리다면.

일단 64비트 OS를 설치하고,

RAM을 넉넉하게 늘리세요. ( 4G 이상, 6G 이상 추천 )

RAM 업그레이드 이후에 체감 링크 속도가 2~3배 빨라졌습니다.

[MySQL] NULL이지만 NULL이 아닌 슬픈 이야기..

U_Seung — Fri, 22 Jan 2010 19:27:13 +0900

일단 어떤 테이블에 varbinary(123) 타입을 가진 컬럼이 하나 있었습니다.

mysql> DESC SomeTable col1;

+-------+----------------+------+-----+---------+-------+

+-------+----------------+------+-----+---------+-------+

| col1 | varbinary(123) | YES | | NULL | |

+-------+----------------+------+-----+---------+-------+

1 row in set (0.00 sec)

이 컬럼에는 NULL이 들어 있었습니다.

mysql> SELECT col1 FROM SomTable LIMIT 0, 10 ;

+------+

| col1 |

+------+

| NULL |

+------+

10 rows in set (0.00 sec)

Stored Procedure를 통해서 여러개의 테이블에서 여러개의 컬럼을 읽는 프로그램이었는데... 디버깅 끝에 이 부분부터 꼬이기 시작한다는 것을 발견했습니다.

그리고 희한하게도 이 컬럼을 읽는 부분에서 NULL이 아닌 값을 읽고 있는 것을 발견했습니다.

그리고... 확인결과 ... 진짜 NULL이 아님을 알았고

mysql> SELECT col1 FROM SomeTable WHERE col1 IS NULL LIMIT 0, 10 ;

Empty set (0.00 sec)

비극의 진실은...

mysql> SELECT col1 FROM SomeTable WHERE col1 = "NULL" LIMIT 0, 10 ;

+------+

| col1 |

+------+

| NULL |

+------+

10 rows in set (0.00 sec)

.......... oTL

한 가지 고려해볼 수 있는 사항은

Binary 컬럼은 SELECT시에 *(asterisk)를 쓰지 않고, HEX(col1) 처럼 HEX() 함수로 감싸도록 (마음속으로.. ) 강제 하는 방법.

[Linux] 콜스택이 깨진 Core 파일 디버깅 하기

U_Seung — Mon, 18 Jan 2010 22:56:48 +0900

Linux에서 Daemon을 돌리다 보면 버그로 인해서 프로그램이 Crash 되는 일이 종종 있습니다.
당연히 문제가 되는 부분 찾아서 고쳐야 합니다.

그럴때 대부분 사용하는 방법이 Process가 죽기전에 기록을 Core파일에 남기도록 설정 하는 방법 입니다.
정상적으로 남겨진 Core파일 경우라면 디버깅 하는게 큰 문제는 없을 테지만
아래와 같이 콜스택이 깨져 보이는 난감한 상황을 만들어 내기도 합니다.

Loaded symbols for /lib/tls/librt.so.1

Reading symbols from /usr/lib/libggauth2.so.56...done.

Loaded symbols for /usr/lib/libggauth2.so.56

#0 0x02d10100 in ?? ()

(gdb) bt

#0 0x02d10100 in ?? ()

#1 0x01010000 in ?? ()

#2 0x000002d2 in ?? ()

콜스택이 깨져 보이는 경우는 주로 Stack Buffer Overrun 으로 인한 문제 입니다.
(다른 문제는 이 글에서 다루지 않습니다.)
이 경우, 스택에 있던 Return Address가 지워져 있기 때문에 GDB는 콜스택을 표시하지 못합니다.

하지만 이런 경우라고 해서 너무 낙심할 것은 아닙니다.
Stack Buffer가 조금 넘친 경우에는 남은 정보를 이용해서 문제를 해결 할 수 있기 때문입니다.

이때, 실마리를 제공해주는 것은 Register의 ESP 입니다.
비록 원하던 Return Adress는 지워졌지만 ESP는 값은 정상적인 값을 유지하고 있습니다.
이제 ESP가 가르키던 메모리 주변을 뒤져서 Return Address와 유사한 값들이 있는지 찾아보면 문제에 대한 힌트를 얻을 수 있습니다.

일단 Return Address랑 유사한 녀석들은 어떤 녀석이어야 하는지 파악 해야 합니다.
당연히 Return Address는 실행가능한 Instruction 들이 저장되어 있는 Code Segment를 가르키고 있습니다. GDB에서는 maint info sections .text 명령어를 통해서 Code Segment를 찾아 볼 수 있습니다.

(gdb) maint info sections .text

Exec file:

`/home/aa/bb.debug.1f25cf3be302bd7308d598c132ac904b', file type elf32-i386.

0x08051e20->0x0824fc08 at 0x00009e20: .text ALLOC LOAD READONLY CODE HAS_CONTENTS

Core file:

`/home/aa/core.1214458224.bb.30678', file type elf32-i386.

이제 Code Segment의 범위도 구했으니 ESP를 기준으로 주변 탐색해서 Return Address와 유사한 녀석들을 찾아 본다면 아마 콜스택과 유사한 모양이 만들어 질 수 있을 겁니다.

이를 위해서 간단한 User-defined Command를 만들었습니다.

define findsymbols
set $textbegin = $arg0
set $textend = $arg1
set $si = $arg2
set $ei = $arg3
while $si < $ei
set $value = *(int*)$si
if ($textbegin <= $value && $value <= $textend)
printf "[0x%08x] ", $si
info symbol $value
end
set $si = $si + sizeof(void*)
end
end

가독성이 다소 떨어지긴 하지만 동작은 간단합니다.
주어진 범위를 탐색하면서 정해진 범위의 값(Code Segment의 범위)이 들어오면..
해당 값을 info symbol 을 이용해서 출력하는 Command 입니다.

실제로 사용하면 아래와 같은 결과를 얻을 수 있습니다. (함수 이름은 가명..)

(gdb) findsymbols 0x08051e20 0x0824fc08 $esp-1024 $esp+1024

[..] IoHandler::SendPacket(char const*, unsigned int, bool) + 786 in section .text

[..] IoHandler::UniCast(char const*, unsigned int) + 26 in section .text

[..] Remote::PartyCast(Party*, char const*, unsigned int) + 141 in section .text

[..] Dispatcher::Do(Task*, TaskMsg*) + 795 in section .text

[..] Task::ExtractTaskMsg(TaskMsg*) + 953 in section .text

[..] Task::svc() + 510 in section .text

콜스택(?)을 얻었으니 ESP값과 비교 등을 통해서 어느 지점에서 Crash되었는 지를 파악할 수 있을 것입니다. 아마 있어야 하는 함수 1~2개가 누락되어서 보이는 경우가 대부분 일테고요. 어떤 함수가 버퍼를 넘치게 했는지 찾아내면 됩니다.

좀 더 정확한 원인을 얻어 보기 위해서는 GDB의 x 명령어 등을 이용해서 ESP 주변 메모리를 잘 뒤져보면 답을 찾을 수 있습니다. 하지만 이 정도 까지 얻었다면 소스를 보고 문제의 원인을 먼저 찾고 문제점이 맞는지 검증하는 편이 더 빠를 수 있습니다.

그럼 즐거운 디버깅 되세요 :)

내 책상 (2010)

U_Seung — Wed, 13 Jan 2010 15:57:08 +0900

(사진 찍은 날짜는 사진 우측 위에 표시.)

아시는 분은 아시겠지만

저는 온라인 게임 서버를 만들고 있습니다.

모니터는 세 대를 사용합니다.

본체는 두 대를 이용하며, 두 컴퓨터는 Input Director로 연결해서 사용합니다.

(지금은 내부 사정으로 서브컴퓨터를 사용하지 못하고 있습니다만,

서브 컴퓨터의 용도는 주로 웹서핑이나 모니터링 툴을 사용하는 목적으로 썼습니다. )

키보드는 원래 기계식을 쓰다가 너무 시끄러운것 같아서 i-rocks를 씁니다.

근데 요즘 가끔씩 손목이 아파서(원인은 잘 모르겠지만..)

Microsoft의 Natural Keyboard로 바꿀까 말까 고민하고 있습니다.

키보드 아래에는 Post-It을 붙이는 장소입니다.

할일이 생기면 Post-It을 붙이고, 그 위에 적어 둡니다.

할일을 다 하면 두줄로 긋고, Post-It에 적힌 리스트가 모두 두줄로 그으면 Post-It을 버립니다.

주로 쓰는 프로그램은 Microsoft Visual Studio 2008 입니다.

Linux에서 돌아가야하는 Application을 만들지만 Linux에서 개발/디버깅은 불가피한 경우가 아니면 하지 않습니다.

Visual Studio을 쓸때는 양쪽 화면에 꽉차게 창 크기를 늘려서 씁니다.

이렇게 쓰면 창 두개를 한 화면에 볼 수 있어서 편리합니다.

(사진에서는 파일 하나만 열었네요.)

색상은 검은 바탕을 선호하며, 폰트는 Bit Stream Vera Sans Mono를 씁니다.

위대한 발견: Visual Studio 검색창 늘리기

U_Seung — Tue, 22 Dec 2009 19:44:46 +0900

그림의 오른쪽 아래 동그라미 쳐진 곳을 주목하면 된다.

저 상자가 늘어난다는 것..

매일 쓰던 툴에서 발견한 신선함 이랄까;;;

Vim으로 여러 파일 Tab으로 열기

U_Seung — Sat, 31 Oct 2009 20:50:06 +0900

일단 회사에 보면 대부분이 U모 Editor를 사용하고 있다.
훌륭한 프로그램이라고 생각하지만 그냥 안 쓰다보니 설치도 안했다.

나는 주로 Windows에서도 Vim을 쓰는데..
다른 사람들에 비해서 여러개의 파일을 다루는 것이 불편하다는 것을 알게 되었다.

그래서 위와 같이 Vim의 Tabs 기능으로 자주 쓰는 파일을 열어야 생각이 들었다.
일단 생각하고나니 문제가 간단해졌다.

CD F:\TT\
gvim -p *.xml

자주 쓰는 파일 목록을 따로 저장해서 열어주는 방식도 있겠지만..
난 이 정도로 충분했다.

두 개의 바로가기를 만들었는데
하나는 *.xml을 읽어 주고, 하는 *.ini를 읽어 준다.

이제는 다른 사람보다 편해졌다. :)

슬픈이야기...

U_Seung — Fri, 12 Jun 2009 09:28:38 +0900

[root@localhost root]# gcc homework1.c -o homework1.c
[root@localhost root]#
[root@localhost root]# ls
homework1.c
[root@localhost root]#

[root@localhost root]#

보기만 해도 가슴이 미어지는 정말 가슴 아픈 이야기.......

내가 쓰는 방법은..
Vim으로 파일을 열고, Ctrl-Z 로 suspend 시켜서 컴파일 하는 방법..
그리고, 작업이 완전히 끝나기 전까지는 Vim을 닫지 않는다.
이렇게 하면 소스 파일이 다른 요인에 의해서 날라가더라도 Vim 프로세스 메모리에 저장되서 안전하다.

두번째 주의할 사항은.
저런 무자비한.. 자비없는 명령을 한번 실행했다면.;
Bash Command History를 날리고, Bash를 재시작 하는 것..
더욱 더 끔찍한 일은.. 저런일이 반복 되는 것이기 때문에...

F#, Project Euler - Problem #4 (2)

U_Seung — Fri, 22 May 2009 11:03:34 +0900

참조: F#, Project Euler - Problem #4

Project Euler를 F#으로 푸는 작업은 계속 틈나는 대로 하고 있는데..

안그래도 구독자가 별로 없는 블로그에 계속 그것만 올리면..

구독자들에게 짜증을 줄까봐 자제하고 있습니다.ㅋ

아무튼 Neon군이 리플로 제안한 방식으로 구현해보았습니다.

일단 기존 방식은 무식하게 세자리 숫자의 곱을 모두 계산 하는 방식이었는데

새로운 방식은 세자리 숫자의 곱 중에서 큰 수 순서대로 숫자를 뽑습니다.

그리고, (123 * 312) 과 (312 * 123)은 같은 값이기 때문에 한번만 계산 합니다.

set [ (999*999, 999, 999) ]

|> Seq.unfold (fun pq ->

let head = pq.MaximumElement

let product, a, b = head

let newElements =

set [ ((a-1)*b, a-1, b); (a*(b-1), a, b-1) ]

|> Set.filter (fun (_, a, b) -> a <= b)

Some (product, ((pq.Remove head) + newElements)))

|> Seq.filter is_parlindrome

|> Seq.hd

|> printfn "Problem #4 = %d"

Priority Queue 구현에서 일반적으로 사용되는 Heap를 사용하는 것이 가장 좋아 보이지만...

F#에서 쓰기 쉬운 Set (Binary Tree) 기반으로 구현 하였습니다.

F#, Project Euler - Problem #12

U_Seung — Tue, 12 May 2009 13:58:39 +0900

Problem #12. What is the value of the first triangle number to have over five hundred divisors?

번역: 500개가 넘는 (양의) 약수를 가진 첫번째 triangle number는 ?

먼저 triangle number의 수열은 아래와 같이 구할 수 있다.

Version1. 정의에 가까운 가장 직관적인 방식..

let triangle_numbers =

let rec triangle_number =

function 0 -> 1 | n -> (n + 1 + triangle_number (n-1))

Seq.init_infinite triangle_number

Version 2. Recursive call을 제거..

let triangle_numbers = Seq.unfold (fun (n, i) -> Some(n, (n+i, i+1))) (1, 2)

Version 3. 최적화.

let triangle_numbers = Seq.init_infinite (fun n -> (n+2)*(n+1) / 2)

triangle number의 수열을 구했으니 답을 구하면..

let factorize n =

let rec factorize_horse n factor count result =

if (n <= 1) then

count::result

else

match (n % factor) with

| 0 -> (factorize_horse (n/factor) factor (count+1) result)

| _ -> (factorize_horse n (factor+1) 0 (count::result))

factorize_horse n 2 0 []

|> List.filter (fun x -> x<>0)

let factor_count n =

factorize n

|> List.map (fun x -> x+1 )

|> List.fold_left (*) 1

triangle_numbers

|> Seq.filter (fun x -> 500 < (factor_count x))

|> Seq.hd

|> printfn "Problem #12 = %d"

약수의 개수를 빨리 구하려고, 소인수 분해를 하였다.

약수 개수를 구하기 위해 모든 약수가 무엇인지 다 파악한다면..

얼마나 느릴지는 장담할 수 없음. ㅋ

F#, Project Euler - Problem #20

U_Seung — Tue, 12 May 2009 13:42:14 +0900

Problem #20. Find the sum of the digits in the number 100!

번역: 100! 값의 모든 자릿수의 합을 구하시오.

여러가지 방법이 있을 수 있지만.

가장 직관적인 방법은 계산해서 더하면 된다.

open Microsoft.FSharp.Math

(BigInt.Factorial (BigInt 100)).ToString()

|> Seq.map (fun x -> (int x) - (int '0'))

|> Seq.sum

|> printfn "Problem #20 = %d"