http://moogi.new21.org/tc/ 철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다. 2022-02-06T13:13:30+09:00 Textcube 1.7.8 : Con moto (주의사신) http://moogi.new21.org/tc/529#comment1702 2011-06-22T08:55:10+09:00

1. 졸업 작품 만들 적에 변수 초기화를 하나 안 했더니, 디버거에서는 돌아가다가, 실제로 실행하면 안 되고, 또 어떻게 빌드하면 디버거에서는 안 돌아가고, 실제 실행하면 돌아가고.... 이 문제의 원인을 찾느라 한 나절 반 정도 썼던 것 같네요. 그리고서 내린 결론. "버그는 운이나 우연에 의해 생기는 것이 아니라 잘못된 개발 습관에 의한 필연적인 결과이다." 2. 들어보셨겠지만, printf 같은 것을 사용했을 때 버그가 사라지는 것을 '하이젠버그'라고 합니다. 원자 등을 다루는 세계에서는 빛을 쏘면 광자랑 입자가 충돌해서 그 성질이 변하기 때문에 잘 관찰하기 어렵다는 '하이젠베르그의 불확정성 원리'에서 출발한 용어이지요. 3. 졸업 작품 프로젝트 할 적에는 Debug 빌드 자체를 없애 버렸답니다. Lua Dll의 최적화 레벨(3)과 프로그램의 최적화 레벨(2)가 충돌해서 버그를 만들어내더군요. 이거 해결하려면, 모든 Dll의 Debug버전을 구해야 하는데, 이건 아무리 생각해도 아닌지라.... 4. Release 버전 빌드 시에는 다음 프로그램을 사용해 주면 좋습니다. http://ospace.tistory.com/113 DbgView라는 프로그램인데요. OutputDebugString의 내용을 보여 줍니다.

(사무엘) http://moogi.new21.org/tc/529#comment1703 2011-06-22T14:13:20+09:00

의견 감사합니다. ^^ 1. 초기화되지 않은 변수는 정말 만악의 근원입니다. 배열이나 구조체 멤버는 컴파일러가 제대로 체크도 못 하기 때문에 상황이 더욱 심각하죠. 초기화되지 않은 변수라는 개념 자체가 존재하는 언어가 C/C++말고 또 있을까 싶습니다. 2. 하이젠버그 맞습니다. 뭔가 사고가 나면 일단 현장 보존이 최우선인데... 저건 read-only operation조차 상태를 바꾸는 operation으로 바꾸면서 개발자를 더욱 패닉에 빠뜨리는 상황이죠. 3. 모듈간에 debug와 release configuration이 충돌하는 건 보통 C 라이브러리의 충돌 때문인 경우가 많습니다. debug CRT를 쓰는 DLL이 malloc해서 넘겨 준 포인터를 release CRT를 쓰는 EXE가 free하는 경우.. 더 말이 필요 없죠. 이것도 엄밀히 말해서 그리 좋은 디자인이 아니며, DLL은 자기가 쓰는 메모리 할당/해제 함수를 외부에도 공개해야 할 것입니다. 4. 사실, 윈도우 NT 계열에서도 OutputDebugStringW는 내부적으로는 버퍼를 ansi로 바꿔서 A 함수를 호출한답니다. 따라서 디버깅 로그에는 원래 유니코드 문자가 표기되지 않습니다.

(김 기윤) http://moogi.new21.org/tc/529#comment1704 2011-06-22T16:47:11+09:00

1. 초기화되지 않은 변수-_-로 피해를 입은 적인 한두번이 아니다보니 이쪽은 아예 도가 터버렸습니다. 2. Debug모드와 Release 모드의 속도차이-_-로 발생한 버그는 저도 겪어본 적이 있습니다. 프로그램이 실행 된 뒤 경과 시간을 얻어내는 함수를 사용해서 그 값을 Rand의 seed 로 주는 코드에서 문제가 발생했었는데, debug모드는 잘 되는데 release모드에서 안 된 이유가 하필이면 그 seed 로 0이 들어갔는데, 0 에서 문제가 발생하는 rand 코드였던...

(사무엘) http://moogi.new21.org/tc/529#comment1705 2011-06-23T00:54:57+09:00

C/C++로 본격적인 프로그램 개발을 해 본 분이라면 본문 내용에 정말 공감할 겁니다. =_= 이거 다음으로는, DLL과 EXE 사이에 함수 calling convention이 일치하지 않아서 괴상한 버그가 발생하던 게 저의 기억에 남습니다.

(김 기윤) http://moogi.new21.org/tc/529#comment1706 2011-06-23T16:28:17+09:00

그러고보니 꽤 유니크한 경우로 Debug에서 빌드가 안되고 Release 에서 빌드가 되던(컴파일은 양쪽 다 되는데 Debug쪽에서 링킹 거부) 괴상한 상황이 있었는데, 나중에 알고보니 사용한 라이브러리는 Multithread-Debug 인데 현재 프로젝트에서는 Multithread-Debug DLL 의 불일치로 인해서 생긴 링킹거부였던 적도 있습니다. 다만, 원인을 알기 전까지는 1주일가량 삽질의 삽질을 거듭했었죠. orz

(사무엘) http://moogi.new21.org/tc/529#comment1707 2011-06-23T23:36:38+09:00

http://minjang.egloos.com/2146607 참조. 말씀하신 것처럼, C 라이브러리의 사용 형태(특히 static이냐 DLL이냐)가 모듈간에 꼬여도 정말 무진장 골치 아프죠. 링크 에러는 컴파일 에러와는 달리 행번호 정보도 안 나오니 더욱 난감합니다. 소스 코드뿐만이 아니라 프로젝트 설정이나 컴파일 옵션이 잘못되어 나기도 하는 에러이니까요.