도데체 malloc을 하다가 죽는건 왜 그런건가요...
글쓴이: kukuman / 작성시간: 월, 2003/10/13 - 7:11오후
stack이 깨진 것 같다고 하는데,,,
다음은 gdb back trace 결과 입니다...
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 5003)] 0x4207a499 in chunk_alloc () from /lib/i686/libc.so.6 (gdb) bt #0 0x4207a499 in chunk_alloc () from /lib/i686/libc.so.6 #1 0x4207a148 in malloc () from /lib/i686/libc.so.6 #2 0x0804c8f5 in ChildProcess (s=4) at nw_child.c:251 #3 0x0804e210 in main (argc=1, argv=0xbffffb54) at nw_main.c:173 #4 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6
혹시 터미날 상에서 메모리 누수를 체크할 수 있는 좋은 프로그램 없나요? ^^
MALLOC_CHECK_을 2로 설정하고 돌려봐도
SIGSEGV가 걸립니다...
혹시 비슷한 경험 하셨던 분들 계시거나 조언해주실 것이 있는 분들의 조언을 부탁드립니다~
도와주세요~ ㅜ.ㅜ
Forums:
freshmeat에서 leak이라고 검색해보세요.저는 leakb
freshmeat에서 leak이라고 검색해보세요.
저는 leakbug라는 라이브러리를 써봤는데...
쓰기 쉽고, 그냥 그냥 괜찮더군요.
Lum7671's Weblog
Re:
보통, 도무지 메모리 에러가 나지 않을 부분에서 난다면..
원인은 에러가 난 부분이 아니라 그전에 메모리를 건드리는 부분에 있죠.
결국은 malloc 디버거들이 잡아내 주어야 하는 문제인데...
가끔 이 녀석들도 못 잡는 경우가 있습니다 -_-
이럴땐 일일이 노가다 하는 수밖에는 없습니다..-_-;;;
메모리 관련 연산을 수행하는 모든 코드를 찾아서 일일이 체크해 보는 수밖에요..
체크하는 것도...그냥 포인터 값을 찍어보는 것보다..
의심되는 코드 앞뒤에 malloc(), free()
를 넣어서 메모리를 직접 건드려 보는게 좋습니다..
valgrind 나 efence를 한번 사용해보시길 권해드립니다.
valgrind 나 efence를 한번 사용해보시길 권해드립니다.
제 생각에는 GDB 결과만 가지고는 잘 모르겠고
1. 널 프린트.
2. 중복 설정/해제.
둘중에 하나 같아 보입니다.
감사합니다~
답변들 모두 감사드립니다~
지금 dmalloc을 가지고 디버깅 해보려고 하고 있습니다~ :)
항상 이곳에서 도움을 얻네요~ ^^
Be at a right place at a right time...
댓글 달기