요즘에 코딩하는 학생들 좀 보니까...

흠... 제가 딱 그런 스타일인데... -_-;

일단 막 코딩하다가... 컴파일해서 돌려보고

이상한 부분을 추측해서 찾거나 printf를 이용하고... ;;

하다하다 안되면 gdb같은거 돌려보구요...

그럼... 어떻게 하는게 좋은 방법인가요?

음 간단하게 죽는 거라면 printf나 파일 로그로 찍어서 해결하지만
한 두세번 해서 안되면 gdb로 진행을 합니다.
(심볼로딩이나 기타 작업으로 구차니즘의 압박이긴 하지만
일딴 디버깅 모드로 진입하면... 안잡히는 것은 거의 없더군요..)

디버거를 바로 사용하는 것 보다 (가능하다면) printf등을 사용하여 에러가 나타나는 곳이 어느 곳인지 범위를 좁히고 그 주변의 코드를 관찰하여 해결하는 것이 먼저 아닌가요?

저는 그런 코드 관찰을 통해 해결 되지 않는 경우에만 디버거를 동원하는데...

최근의 작업에서는 동료와 짝 프로그래밍을 많이 해서인지 코드 관찰을 통해 거의 모든 버그를 해결했습니다.
(디버깅이 무지 힘든 임베디드 환경이기도 했지만... ;) )

저의 방법이 꽤나 일반적이라고 생각하는데 그렇지 않나요?

ps. 뭐, 전문 서적 같은 것은 읽어 보지 못해서 잘 안다고 할 수는 없네요.. ;;;

으... 이거 글삭제 어떻게 하지요?

저는 디버거도 쓰지만, 잘은 안 씁니다. 그대신, 기본적으로 어느 정도의 assertion을 깔아놓고 코드를 짭니다.
심할 때는 수행하는 코드 반, assertion 반, 뭐 이럴 정도입니다-_-;

눈으로 노려보는 것, 저도 자주 합니다-_-; 이유는 대충 두가지쯤 되는 것 같군요.

1) 어디까지 assertion이 통과되었는지 생각하면서, 눈으로 30초만 노려보면 어디가 잘못되는지 보이는 경우가 많음. (이런 경우는 사소한 실수인 경우가 많으며, 노려봐야 할 코드의 범위가 생각보다 적기 때문에, 할만합니다...)
2) 정말로 뭘 어떻게 살펴봐야 할지 모르겠어서 (디버거로 돌리고 돌려도 데이터가 다 맞는데 모르겠는 경우, 혹은 데이터가 뭔가 잘못 들어온 게 맞는데, 그 잘못된 데이터의 근원지를 도무지 알 수 없을때)

저는 디버거를 그렇게 좋아하지는 않습니다. 오히려 대량의 assertion을 깔아놓으면, 어느 부분이 잘못되었는지 찾기가 쉬운 것 같더군요.

음... 저의 경우에는 요즘은 알고리즘 구현을 많이 합니다. 그래프 알고리즘, 뭐 이런거요...

저도 예전에 디버거를 안 쓰고 개발을 하는 것은 불가능하다고 생각했었습니다.
근데 얼마전에 놀라운 사람을 봤었습니다.... 얼마전에 학회에 갔다가, 현재 IBM에서 코드 검사를 하는 툴을 개발하는 사람을 만났습니다...
(코드를 실제로 수행시키지 않고 포인터 에러의 가능성이라던지, 버퍼 오버플로우를 검사해주는 프로그램들)

분명 컴파일러 종류의 애플리케이션이기 때문에 엄청나게 복잡한 프로그램일텐데, 이런 사람들은 어떻게 개발을 할까 궁금해서 물어봤는데, '나는 디버거를 쓸 줄 모릅니다.' 라고 자신있게 얘기하더군요.. 그럼 어떻게 개발을 하는가 물어봤더니, '자기 자신의 프로그램에 대해서 논리적으로 옳도록 한다'고 하더군요-_-;;; 뭐 정확히는 이해를 못 했지만, 자신이 짜는 프로그램에 대해서, '예외사항이 없는 경우'임을 명확히 증명을 하고 그다음에 들어간다는 식인 것 같았습니다.

뭐 저나 그 사람이나 시스템과 강하게 상호작용을 하는 프로그램을 만드는 것이 아니며, 명백한 single-thread인 경우에 코딩을 하고 있기에 가능한 일일지도 모르겠습니다. 근데 많은 경우에는 디버거 없이 자체 생산한 debug log들과 assertion으로 해결이 되는 것 같더군요.

요즘은 vc++을 쓰는데, TRACE() 매크로랑 ASSERT() 매크로를 씁니다. (매크로 맞죠?) gnu환경에서는 나름대로 dprintf() 함수를 만들고, ASSERT() 매크로를 만들어서 씁니다.

그 후배들이 제대로 하고 있는것 같군요.

사람의 취향마다 다르긴 하겠지만, 정석대로라면 무턱대고 디버거를 돌리는것보다는 먼저 코드리뷰를 하는것이 맞습니다.

(코드를 째려보는것도 좋은 코드리뷰의 한 예죠.)

저는 개발시 될 수 있으면 디버거는 돌리지 않는 스타일입니다. 문법오류를 제외한다면 대부분의 오류는 생각했던 프로그램의 로직이

예상밖의 행위를 할때 발생합니다. 예상밖의 행위를 예상범위 안으로 포함시키는것이 에러의 원인을 애초에 코드상에 투입시키지 않는 방법이 됩니다.

디버거로 디버깅을 하는 행위자체는 '결과'를 가지고, '원인'을 추적하는 것이지만, 코드리뷰는 '원인'자체를 찾아 그것을 방지하는 방법이기 때문에

순서상으로 봤을때 코드리뷰를 하고서 디버거를 돌리는것이 디버거만 사용했을때보다 훨씬 효과적입니다.

cinsk 님

메모리 닉을 찾아내는 것에 대해 조금더 설명해 주실 수 있나요?

네트워크 프로그래밍을 하다보니 이게 잘 돌다가도

가끔 닉이나서 엉망이 되버리는 경우가 생긴다고 하더라구요.

규칙적으로 그런것도 아니라서 찾기도 힘들다고 하던데..

메모리 닉을 찾는 디버깅 기법을 꼭좀 알려주시면 감사하겠습니다.

여기까지 읽어보니 디버거를 쓰는 사람들이 더 많은 듯합니다.
요즘은 그런 모양이죠?

printf 말고는 디버거를 사용해 본적이 없는 사람인데 ..
(개인적으로 디버거를 사용하는건 초보나 하는짓이다.. 이렇게 생각합니다만)
장점도 있는 모양이군요..

이상하긴 합니다.
자기가 짠 프로그램이 논리적으로 이상이 있는지도 모른다면 그건 누가 짠겁니까? 보조수단이어야 할 디버거가 주력이 되어야 하다니..

어쨌든 ..
조금 의외긴 합니다.

저도 아직 초보라서 그런지 디버거 없으면 디버깅 하기 힘들더군요..
디버거 없으면 당장 어떻게 먹고 살 지 앞이 깜깜합니다. T_T

맞아요. 저같은 사람은 프로그래머축에도 못끼게 되어버려요. T-T

부끄러운 이야기지만
울 팀은 프로그래밍 실력자가 없어서리...

전에 외부에 파견나가서 프로그래밍을 할 일이 있었는데
거기 연구원들은 실력이 워낙 출중하기로 자타가
공인한 분들이었죠.

그래서 다른 건 몰라도 이 사람들 디버깅을 어떻게 하는지
어떤 툴을 사용해서 어떻게 접근하는지
확실하게 배워오리라 맘 먹었습니다.

가서 옆에서 봤더니
printf 를 마구 찍더군요. -_-;;
다만 똑같이 찍어도 뭐가 문제인지 판단하는 능력에서
차이가 난다는...

초보자의 경우 혹은 경험이 부족한 개발자의 경우, 앞날을 생각해서라도, 삽질해보는 것도 괜찮은 방법이라고 생각합니다.
물론 gdb와 같은 디버거가 강력하다고는 하지만, 삽질의 노하우도 아주 그에 못지않게 중요하다고 생각합니다.

$ info libc memory "memory allocation" "allocation debugging"

을 쳐 보시면, mtrace/muntrace 레퍼런스와 사용 예제가 나옵니다.

동감입니다. 저도 assert(3)을 매우 애용하는 편입니다.

웬만하면 소모적인 논쟁은 하고 싶지 않습니다만:

전 이 말에는 동의할 수 없을 거 같습니다.

주로 이론에 치우치신 분들이 이런 말씀을 하시는데, 흠.. 글쎄요. logical이라는 말을 어떻게 해석해야 될 지 사실 전 막막하기만 합니다. logical을 program algorithm을 의미한다고 가정해도 될까요? 쉬운 예로 sorting을 아주 그럴듯하게 잘 설계를 하고 코딩에 들어 갔습니다. typing miss로 conditional expression (foo == 0)을 (foo = 0)으로 썼다거나, 변수 초기화를 빼먹었다거나, 등등.. 이런 에러를 logical error라고 할 수는 없겠죠? 그럼 debugger 쓰시는게 빠릅니다.

그런식으로 자신있게 (얄밉게) 말해보라면 저는 이렇게 말하고 싶군요:

저는 debugger를 애용하는 편입니다. 제가 작성한 코드는 논리적으로 하나의 결함도 없고, 단지 가끔 위에서 말한 사소한 실수만 있을 뿐이므로, 이런 것들만 debugger로 잡아주면 남보다 훨씬 빠르죠. Code review? 논리적으로 결함이 없으니 할 필요도 없고요..

아 물론 제가 진짜로 저렇게 말하고 다니거나 저렇게 생각한다는 건 아닙니다. ^^;

음.. 갑자기 이 커트(아래 첨부)가 떠오르는군요: A.J.가 DOS EDIT 프로그램을 써서 편집하는게 끔찍했다고 하니, Mike는 edlin을 썼다고 뻐김. A.J.는 다시, 자신은 COPY CON을 썼다고 뻐기고. Mike는 ECHO를 썼다고 우김. 서로 욕하고 있는데, Miranda가 와서 자신은 자석으로 inode를 직접 편집했다고 얘기함: User Friendly 만화랍니다. Best of the best of the best geek comics!

음.. 조금 과장한다면.. ihavnoid님이 인용하신 IBM programmer분, debugger를 안쓰신다는 분들 editor는 무엇을 쓰냐고 묻고 싶군요. 논리적으로 완벽하게 머릿 속에서 정리되어 있고, 결함이 없게 작성되어 있다면, ed(1)도 필요없을 거 같고, DOS/Windows라면 COPY CON으로, *nix family라면 cat >> file 로 충분할 거 같다고 말해 주고 싶습니다. 아니, compiler도 필요 없겠군요. C로 작성한다면 C 문법 패턴을 machine lanauge code로 매핑해주는 테이블을 기억에 두었다가 그냥 쓰시면 될텐데요..

그분 일이 "코드 검사를 하는 툴을 개발"하는 것이라는데,, 훗. debugger는 필요없으면서 그런 툴은 필요해서 개발하나 보군요.

욕하실 분이 있을지는 모르겠습니다만, 제 주변에서 debugger를 안 쓰는 분들은 대부분 "배우기 귀찮아서"가 현실적인 이유였던 것 같습니다.

물론! debugger를 쓸 수 없는 환경은 당연히 예외겠죠. Kernel porting하면서 printk만 쓸 수 있다거나, embedded boot loader 관련이면 더욱 심할테고요.. 그 때 쓰는 ICE, TRACE32 등등의 JTAG debugger도 debugger이긴 하네요.

지금까지의 경험으로는 이런류 -- 수백번씩 루프가 있는 손으로 쫓아가기 힘든 프로그램들 -- 은 절대 디버거가 print를 따라갈 수 없다고 생각합니다. 전 회사에서 몇년 작업하던 프로그램이 대강 이런 종류의 프로그램인데, 디버거로 watchpoint 부터 시작해서 별짓을 다 해봤는데도 printf가 훨씬 편하더군요. 물론 로그가 수백줄 쌓인다는 문제도 있긴 합니다만... 흐흐...

하지만, 역시 저도 -- 디버거를 자주 사용하는 것은 아니지만 -- 디버거가 없이는 코딩을 못하는 종족에 속하는 것 같아요 한시간을 코딩하면 한두번쯤은 꼭 디버거와 놀게 되는군요. :-)

print나 디버거나.. 둘다 필요하겠지만, 처음에 글 쓰신분의 의도는...

선택의 여지 없이 printf를 쓰거나 그것 조차도 모르는 것 같은 후배를 말씀하시는게 아닌가 하네요.

경험이 쌓이기 위해서는 시간이 필요하겠지요 :)

한 10년째 이곳 저곳 왔다 갔다하면서 여러 개발환경들을 만져봤습니다.

그런데, 디버깅의 결론은...

1. 코드를 뚫어져라 쳐다봐라. -> 논리의 오류를 찾는다.
2. 값을 찍어본다. -> 논리에 맞게 값이 변화 했는가 확인한다.

이 두가지는 어떠한 환경에서도 사용가능한 가장 막강한 디버깅 방법이더군요.
핸펀 애플 개발시 사용가능한 디버거 있으면 좀 알려주세요.
임베디드 시스템에 개발시 제대로 사용할 만한 디버거 있음 알려주세요.
마이컴 개발시 쓸만한 디버거 있음 알려주세요.

아마도 찾기 힘드실 겁니다.

과거 엠에스의 그늘아래에서 비절씨의 우산아래 있던 시절은 그나마 디버거의 덕이라도 봤지만...

임베디드 시스템에선 비절씨의 디버거가 너무나도 막강해 보이네요.

전 현재 셋탑박스 개발자로 일하고 있는데,
과외의 일로 DVR을 손대게 되서 이렇게 KLDP에 나타났습니다.

여러분들께 많은 도움을 받아야 할것 같습니다.
임베디드 리눅스는 처음이라... ^^

솔직히 하드웨어 쪽에 손대지 않는 이상
디버거 돌릴 일이 별로 없습니다...

왠만큼 삽질을 하다보니
( 배열 1 덜잡아서 오작동 한다거나..
scanf에서 & 안붙였거나...
이런걸 또 1주일 동안 디버그 한다거나... )

코딩미스 보다는
설계 에러가 훨씬더 많더라구요...

설계 에러는 쉽게 찾을 수 있으니
역시 코딩에러를 줄여야겠지요 ^^;;;

삽질도 하나의 좋은 추억과 경험이 아닌가 싶습니다.

저도 임베디드 쪽이라서, 주로 printf에 의존한다는 글을 올릴려고 보니,
2003년도 글이군요.

디버거를 사용하는 게 좋은 습관이라는데는 이견이 없습니다. 게다가 요새는 다들 GUI 디버거가 포함되어있는 IDE에서 프로그래밍하는게 일반적이니 더 그러하겠죠.

저도 win32 application을 만들때는 디버거에 많이 의존하곤 했습니다. printf같은건 써본적이 없었죠. 그런데 회사에 들어와서 임베디드 프로그래밍을 하다보니 printf에 의존하게 되더군요.

뭐 딱히 디버거를 무시하는게 아니라 일단 쓸만한 디버거가 없습니다. gdb를 올릴 수 있긴하지만, 올리는게 또다른 일거리를 만들어 내는 거라서 안하게 되더군요. 또한 주로 커널 작업을 하기 때문에 printk에 의존하는 경우도 많습니다.(몇몇 정보는 proc파일시스템을 이용하기도 합니다) 심지어 제가 일하는 회사는 ICE 장비도 없기 때문에 부트로더 작업할때는 보드의 LED로 printf를 대신하는 경우도 많습니다 :)

이런 식으로 디버거를 별로 안써봐서인지, (제가 주로 하는 일인) 장시간동안 동작하는 과정에서 벌어지는 버그에는 디버거가 별 소용이 없는듯합니다. 제 짧은 견해로는 디버거는 동작을 시켰을때 바로 알 수 있는 버그에만 유용한 듯 합니다. 디버깅 포인트에 언제 진입할지 모르는, 즉, 문제상황이 언제 벌어질지 모르는 경우에는 printf나 log를 이용하는게 훨씬 좋은 방법이라고 생각이 듭니다.

물론 assertion을 이용하는게 좋을 거라는 생각을 하고 있기는 한데, 습관을 고치기가 힘들군요.

소프트웨어의 복잡도와도 관련이 있어보입니다.

단순한 기능의 디버거를 사용한다면, 일반 printf와 크게 차이가 없어 보입니다만,

진짜로 디버거를 사용하면 편리한 곳이 많습니다.

저는 solaris의 dbx가 가진 기능중 stop access 라는 기능이 있습니다.

특정 메모리에 대한 접근시 event를 발생하는 것인데,

다수의 쓰레드가 복잡하게 돌아가는 환경에서 corruption 비슷한 동작을 하는

놈을 잡는데는 이이상 편리한 기능은 없다고 생각합니다.

실제로 디버거가 가진 편리한 기능을 알고 나면, printf와는 비교할 수 없을 것이라

생각합니다.

디버거의 유/무용론을 말하기 전에 실제 그 디버거가 가진 모든 기능을 review 하신 후에

하시는 것이 이치에 맞을 것 같습니다.

디버거가 printf의 super set이 아니던가요?

마치 purify와 같은 전문툴을 한번도 사용하지 않고, 메모리 관련 에러는 그런 것 없어도

잘 잡을 수 있다 라고 단정짓는 것과 비슷한 것 같아 드리는 말씀입니다.

물론, case에 따라 다른 것을 사실입니다.

그러나, 무조건 printf가 디버거보다 낫다는 주장은 조금 설득력이 떨어져 보입니다.

김성진

뭐 저도 시스템 구상하고 직접 구현하는 경우는..
디버거는 생각하기 힘든 에러 잡을때 빼고는 잘 안쓰는 편인데요..

이건 그때뿐..

남의 소스 고칠때는 디버거 없이 힘들겠죠?
학교에서 배우는 수준이면 괜찮을까 싶지만.. 여기 계신분들 대부분은 거의 현업이시니..
일단.. 시스템 구조 문서나 api문서가 없는 상태에서
그냥 눈으로 하겠다는건.. 뭐라해야되나.. 자네가 천잰가? 라고 질문하고 싶어진다고 해야되나?

trace나 assert도 결국 자기가 의심스러우니깐 쓰는 것이때문에
남이 짜논 것에 에러가 뜨는 경우는 별 도움이 안될까 싶은데..뭐 아닐수도 있습니다.
프로젝트의 크기라던가.. 어떤 환경이라든가.. 차이가 있겠죵~

하여간 전 지금 하고 있는 일은 디버거가 없으면 쫒겨날지도 모르는 판~ 있어도 힘들구만~

저는 주로 Java 를 쓰기 때문에 stack trace 만 잘 들여다봐도 대부분의 문제는 금방 해결됩니다. (이클립스나 넷빈즈에 있는) 디버거는 binary tree 를 직접 구현한다거나 할때 말고는 써본 기억이 별로 없네요.

개인적으로는 JUnit Test 가 디버거보다 더 유용하다고 생각됩니다. (제가 만나는 대부분의 문제들에 대해서)

http://blog.superwtk.com/

저같은 경우에는 C는 1차적으로 컴파일러 에러,워닝 잡고 나면,
이하 발생하는 모든 오류는 디버거 없이는 도저히 못잡겠더군요.

물론 printf 및 assert 다 쓰지만, 그래도 마지막에는 디버거.

결국 디버거갈 거라, 그냥 디버거 씁니다.

printf는 큼직큼직한 로직 추적용으로만. 그래야 디버거 쓸때도 편하니...

There is no spoon. Neo from the Matrix 1999.

디버그 모드에서는 잘 되는데 일반 컴파일 모드에서는 안 되고.. fprintf를 찍으면 잘 되는데 그걸 안 찍으면 안 되고.. 똑같은 옵션으로 컴파일했는데 gdb 돌리면 잘 되는데 그냥 실행하면 안 되고.... (뭐 세그폴이나 그런 것도 아니고 그냥 block되어버리는...) 뭐 한 10번 실행하면 그 중 한 두번은 잘 되고...

이런 건 어찌해야 할까요? ㅠㅠ

ps. 근데 assert에 대해서 찾아보니 이게 제가 나름대로 만들어서 쓰던 매크로랑 비슷한 기능을 하는 거였군요. manpage 보니까 "디버깅모드에서 사라지는 Heisenbugs(불확정성버그)를 만들 수 있다"라는데.. 바로 이 문제 때문에....-_-;

디버거를 사용해서 편한 경우에는 gdb를 직접 써서 디버깅을 합니다.
물론 printf , file log 등등을 병행해서 처리하구요.
printf등의 log에서 이상한 부분의 범위를 좁히고 디버거에서 확신하는 작업을 하게 되죠.

메모리 버그는 뜬금없이 엉뚱한 부분의 메모리를 깨는 경우가 많으니 자주 깨지는 주소에 브레이크 포인트를
걸어서 잡을 수 있습니다.

gdb에서는 메모리주소에 조건을 걸고 해당 메모리 값이 특정 범위가 아닐때 브레이크 포인트를 걸 수 있습니다.
( VC++에선 6.0에선 안되고 .NET에 와서야 구현된 기능이죠.)

디버거를 쓰냐 printf를 쓰냐는 취향의 문제 겠지만. 못쓰는 프로그래머는 문제가 있습니다.
못쓰는 이유는 call 스택이라든지 메모리 구조 등등에 대한 사전 지식이 없는 경우기 때문이죠.

디버거에 익숙해 지는건 상당히 중요 합니다.
__
Never Ending 삽질.

printf를 넣었을 때는 잘 되고 안 그럴 때는 안 되고 디버거로 돌리면 잘 되고 그냥 하면 안 되거나 죽고... 10번 정도 돌리고 한두번 되고... 이거... 콘솔 디스크립터나 그런 쪽 문제일지도 모르겠군요... 아니면 프로세스 fork 할 때 문제가 생기나요? 아무튼 흐흠...
----
일어나라! 싸워라! 그리고 이겨라!
다만!!! 의미 있는 것에 그 힘을!!!
그 능력과 노력을!!!

모든 분들에게 Steve Maguire씨의 Writing Solid Code를 추천합니다.

디버깅의 과정, 비용(노력,시간), 결과. 이 3가지 측면때문이 아닐까요?

디버깅은 디버거!!

디버깅이 printf()로 편하게 해결이 가능했다면 수많은 디버거가 출현할 이유가 없겠죠.

반면, 디버거도 printf()만큼 쉽게 사용하고, 빠르게 확인가능 했다면 printf()를 쓰지 않았겠죠.

교수님(유닉스세대)들은 디버거도 못쓰면서 어떻게 디버깅을 하냐라고 말씀합니다.

반면 학생들은 그나마 GUI 디버거에서 text 디버거를 쓰라고하면 죽을려고 합니다.

의외로 많은 분들이 이책을 안보신것 같네요. ^^;

어찌된 영문인지, 직장생활 시작해서 지금까지
단일스레드로 돌아가는 프로그램을 짜본적이 없는것 같네요.

멀티스레드에서의 디버깅은 너무 힘들기 때문에, 물론 내공부족이겠지만..
printf에 70%정도 의존하고 있습니다.
valgrind+gdb조합으로 부족한 30%를 채웁니다.. ;-)

좋은글 잘읽고 갑니다~

---
jai guru deva om...

coredump와 assert 는 축복과 같아요 'ㅇ')/

몇일 동안 잘돌다가 퍽~ 죽습니다..아무 메시지 없이..
원인은 둘중하나 입니다.

1. thread 간에 충돌
2. thread 가 돌고 있다가 IO interrup 가 발생해 충돌..

문제는 포인트를 도져히 못찻겠내요..
좋은 툴있으면 추천좀..