gdb 를 사용해서 core 파일을 보았는데... 미치겠네요...
글쓴이: uni2u / 작성시간: 토, 2008/11/01 - 2:11오후
gdb 를 이용하여 core dump 파일을 보았는데 생각보다 자세하게 나오지를 않네요.
GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.9"... Core was generated by `GviScheduler -b -15223 -s GviScheduler -d -1'. Program terminated with signal 11, Segmentation fault. Reading symbols from /user1/prmgwv/tmax/lib/libsvrucs.so...done. Loaded symbols for /user1/prmgwv/tmax/lib/libsvrucs.so Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /user1/prmgwv/tmax/lib/libnodb.so...done. Loaded symbols for /user1/prmgwv/tmax/lib/libnodb.so Reading symbols from /usr/local/lib/libnetsnmp.so.5...done. Loaded symbols for /usr/local/lib/libnetsnmp.so.5 Reading symbols from /usr/lib/libkstat.so.1...done. Loaded symbols for /usr/lib/libkstat.so.1 Reading symbols from /usr/local/ssl/lib/libcrypto.so.0.9.7...done. Loaded symbols for /usr/local/ssl/lib/libcrypto.so.0.9.7 Reading symbols from /usr/lib/libcurses.so.1...done. Loaded symbols for /usr/lib/libcurses.so.1 Reading symbols from /usr/local/lib/libstdc++.so.6...done. Loaded symbols for /usr/local/lib/libstdc++.so.6 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/local/lib/libgcc_s.so.1...done. Loaded symbols for /usr/local/lib/libgcc_s.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/platform/SUNW,Sun-Fire/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Sun-Fire/lib/libc_psr.so.1 Reading symbols from /usr/lib/nss_files.so.1...done. Loaded symbols for /usr/lib/nss_files.so.1 Reading symbols from /usr/lib/locale/ko/ko.so.2...done. Loaded symbols for /usr/lib/locale/ko/ko.so.2 Reading symbols from /usr/lib/locale/ko/methods_ko.so.2...done. Loaded symbols for /usr/lib/locale/ko/methods_ko.so.2 #0 0xfedc7598 in realfree () from /usr/lib/libc.so.1 (gdb) where #0 0xfedc7598 in realfree () from /usr/lib/libc.so.1 #1 0xfedc7e64 in cleanfree () from /usr/lib/libc.so.1 #2 0xfedc6f90 in _malloc_unlocked () from /usr/lib/libc.so.1
Makefile에 -g 옵션을 주고 컴파일을 한 후 core dump를 확인하였습니다.
서비스 바이너리를 만드는데 총 4개의 소스파일이 있어서 그런지 gdb로 확인할때 자세하게 나오지 않네요.
gdb 쪽 문서를 더 보고 있기는 합니다만...
core dump를 확인하고 나니까 조바심이나서...
수많은 경우들 중 보통 어떤 경우가 위와 같은 core dump가 날 수 있을까요?
Forums:
core는 -g 없이 컴파일한 바이너리의 것인가 보네요.
core를 분석하시려면, binary도 core를 생성시켰을 때의 그 녀석이어야 합니다.
그 이유는 맨 위쪽에 있는 warning 처럼, core file보다 exec file이 나중에 만들어졌기 때문입니다. 즉 core를 발생시킨 exec file이 아닌 새 버젼이기 때문에 symbol 등의 위치가 바뀌어 부정확한 callstack 등이 나올 수 있다는 것입니다.
말씀하시는 걸 봐선, 어째 -g 없이 compile한 binary로 돌리다가 발생한 core를 분석하기 힘드니 다시 -g 를 넣어 compile한 binary로 분석을 하시려는것 같은데, 그 경우엔 완전히 엉뚱한 callstack이 나오기 때문에 분석이 안됩니다.
내용을 거의 볼 수 없더라도, -g 없이 compile한 binary를 붙여서 분석을 해 보시던지, 아니면 -g 로 compile한 binary로 다시 core를 발생시켜 해당 core를 분석하시던지 둘중 하나를 하셔야 합니다.
제 경험으로는..
전 아주아주 예전에 바이너리 링크할때만 -g 옵션을 주는 실수를 한적이 있었는데..
전체 소스에 대해서 모든 오브젝트 파일을 생성할때 -g 옵션을 주셔야합니다.
그리고 소스내용만 같다면 -g 옵션을 안주고 생성된 코어덤프 파일일지라도..
-g 옵션을 다시 주고 컴파일한 바이너리 파일로 gdb를 돌리면 제대로 나오던데요...
freebsd에서는 그랬는데 linux는 안그런가요??
정확하게 어떤 원리인지는 모르지만..
테스트를 해봐도 잘 되는걸 보니..
바이너리엔 디버그를 위한 정보만 추가로 담기기때문에 -g 옵션을 주던 안주던 생성되는 코어파일은 동일할겁니다..
코어파일이란것도 당시 메모리정보를 덤프를 뜬것일테구요...
메롱~
댓글 달기