decNumber Library(http://speleotrove.com/decimal/)를 사용하는 코드에서 Call stack을 깨먹는 버그가 발생하여 지난 일주일동안 마음이 편치 않았는데, 결국 해결했습니다! 워낙 사소한 실수에서 비롯된 일이라 부끄럽기 그지 없지만, 유사한 버그로 머리를 쥐어뜯고 있을 누군가에게 도움이 될지도 모른다는 바램을 가지고 용기를 내어 보겠습니다!

Call stack을 깨는 코드는 다음과 같습니다.

이 함수가 호출되면 sementation fault가 발생하면서 프로그램이 죽는 현상이 발생했습니다. gdb에서 bt를 실행해보니 call stack이 깨졌다는 사실을 알 수 있었습니다. 곰곰히 생각해보니 로컬변수에 값을 쓰다가 activation record의 return address 영역을 엎어 쓰는 것 같더라구요. 이를 확인하기 위해 left 변수 앞에 임의로 char buf[100]; 변수 선언을 넣었더니 call stack이 깨지는 현상은 사라졌습니다.

decNumber 라이브러리를 사용하여 실제 계산을 수행하는 코드는 다음과 같습니다.

여기서 눈여겨 보아야 할 것은 DECNUMDIGITS라는 상수(constant)입니다. 항상 decNumber를 사용해 계산을 수행하기 위해서는 decContext를 설정해서 전달해 주어야 하는데 이때 DECNUMDIGITS을 참조하게 되죠. 이 값을 별도로 설정하지 않으면 decNumber.h에서 1로 설정하기 때문에 정상적인 연산을 수행할 수 없습니다.

따라서 decNumber로 표현 및 계산하고자하는 최대 자리수를 #define으로 미리 지정해 주어야 합니다.  문제는 여기에 있었습니다. decNumber를 사용하여 계산하는 함수를 따로 분리하는 과정에서 decNumber.h를 include 하는 문장 뒤에 #define DECNUMDIGITS를 포함하는 헤더파일의 include 문장이 존재하게 되었던거죠! 결과적으로 decNumber.h가 확장될때는 DECNUMDIGITS가 기본값인 1로 결정되고, 제가 작성한 코드에서는 프로젝트 전역 헤더파일에서 정의한 값(30)이 참조되었습니다. 변수와 정의와 변수의 참조 사이에 괴리(?)가 발생했던 겁니다. 

decNumber.h를 살펴보면 문제는 좀 더 명확해 집니다.

decNumber.h를 include하는 문장 앞에 DECNUMDIGITS을 정의한 프로젝트 전역 헤더파일을 include하도록 수정함으로써 문제는 간단히 해결되었습니다. 대부분의 버그가 비슷하겠지만, 문제를 찾아서 해결하고 나니 참으로 허무한 기분이 들었습니다. 한동안 제 자신이 미워지더군요. ^^;

이번 경험을 통해 얻은 교훈은 다음과 같습니다.

1. macro 사용에 유의하자.
2. 헤더파일의 include 순서에 유의하자.
3. call stack을 깨는 경우는 문자열을 비롯한 array의 잘못된 사용 및 참조로 발생하는 경우가 많다.

+ Recent posts