core file 분석

제가 주로 쓰는 방법을 말씀드리자면

먼저 gdb <실행화일> -c <core 화일> 하여 디버거를 실행시킨후
아래와 같이 bt(backtrace)명령어로 어떤 함수를 부르다 죽었는지
확인합니다.

(gdb) bt
#0 0xef663628 in fprintf () from /usr/lib/libc.so.1
#1 0x15b0c in fxRslt (gubun=0x56bf0 "1", from=0x57070 "010305",
    to=0x574f0 "010305", loginid=0x57970 "TEST001")
    at /fxMain/SRC/fxWeb/cgi/rslt.c:50
#2 0x1597c in main (argc=1, argv=0xeffff964)
    at /fxMain/SRC/fxWeb/cgi/fxrslt.c:85
(gdb)

보니까 main->fxRslt->fprintf 하다가 죽었군요. 장소는 rslt.c 에 50번째 줄.
이제 frame 명령어로 해당 스택으로 이동합니다. 이후 list 명령어로
소스파일을 확인해봅니다.

(gdb) frame 1
#1 0x15b0c in fxRslt (gubun=0x56bf0 "1", from=0x57070 "010305",
    to=0x574f0 "010305", loginid=0x57970 "TEST001")
    at /fxMain/SRC/fxWeb/cgi/rslt.c:50
50 fprintf(logfile,"GUBUN:[%c] FROM:[%s] TO:[%s] LOGIN:[%s]\n",
(gdb) list
45 loginid[i] = '\0';
46 strcpy(audit_id, loginid);
47
48
sprintf(logfname,"%s/%s.log",FXRSLT_LOGDIR,RSLT_LOGINIT,loginid);
49 logfile = fopen(logfname, "w");
50 fprintf(logfile,"GUBUN:[%c] FROM:[%s] TO:[%s] LOGIN:[%s]\n",
51 gubun[0],from,to,loginid);
52
53 if (ChkDate(from,to)==0) {
54 fprintf(logfile,"Error in ChkDate\n");
(gdb)

그담엔 print명령어등으로 각 변수값을 조사하여 NULL이 있는지 체크해보면
됩니다.
----------------
[스크랩] Java VM Core Dump 분석   조회(41)
 
java 프로그램 | 2005/01/02 (일) 16:17   공감하기(0)  | 스크랩하기(0) 
 
 

대부분의 문제 발생 원인(리스트는 우선 순위가 아닙니다.)
 
1.       해당 어플리케이션이 사용하는 Native 코드 사용시 발생
 
2.       모든 Type 2 JDBC 드라이버는 native DBMS 라이브러리를 사용하므로 이러한 유형의 오류가 발생할 수 있습니다.  이 드라이버가 문제의 원인인지 판별하려면 pure java(Type 4) JDBC 드라이버로 전환합니다.
 
3.       JNI 호출을 사용하여 액세스하는 모든 native 라이브러리도 이러한 유형의 오류가 발생할 수 있습니다.  응용 프로그램에서 이러한 라이브러리를 사용하는 경우 신중하게 조사해야 합니다.  보통 이러한 라이브러리는 응용 프로그램에서 해당 기능을 필요로 하기 때문에 제외시키기 어렵습니다.
 
4.       JVM 자체도 native 프로그램이며 이러한 오류가 발생할 수 있습니다.  JVM이 의심스러운 경우 인증된 다른 JVM 또는 상위 버전을 사용하여 JVM 버그가 오류의 원인인지 파악합니다.  많은 JVM 버그는 JIT 컴파일러 사용과 관련이 있으며 종종 이 기능을 해제하면 이러한 유형의 문제가 해결되기도 합니다.  이 기능을 해제하려면 대개 -Djava.compiler=none 명령 옵션을 사용합니다. 
 
위와 같은 원인 이외에도 발생 원인은 많습니다. Core file이 생성되면 이 Core file을 분석하여 발생원인의 범위를 좁혀 가야 합니다.(발생원인을 좁혀가는 거지 발생원인을 정확히 집어내기는 어렵습니다. – 능력이 출중한 사람은 되겠지요.)
이 문서에서는 Core file 분석 Tool인 dbx나 gdb을 사용하지 않고 각 OS에서 제공하는 Core File분석 툴을 사용 하여 분석하는 방법에 관하여 알아봅니다.
 
참고 : 다음과 같은 경우 Core File이 생성되지 않을 수도 있습니다.
 
•        시스템 또는 사용자 별 ulimit -c(코어 파일의 설정된 크기)를 검사합니다.
•        사용 가능한 사용자 디스크 공간을 검사합니다(예: 디스크 할당량이 있습니까?)
•        Solaris에서는 /etc/system 파일에 다음 매개변수가 있는데 이 값에 따라 코어 파일이 생성되지 않을 수 있습니다. set sys:coredumpsize=0
•        Linux에서는 기본적으로 코더 덤프가 오프로 있습니다.  RedHat Advanced Server 2.1에서는 구성 정보 파일이 /etc/security에 있습니다.  limits.conf라는 파일에서 설정 사항을 확인할 수 있습니다. "core"라는 단어를 찾아보십시오.  0으로 설정되어 있으면 coredump를 만들 수 없습니다.
•        HP OS 설정 커널 매개변수 maxdsiz(max_per_proc_data_size는 사용자 프로세스의 데이터 세그멘트 크기를 늘림) 64M에서 134M 이상으로 변경합니다. 

 
Core File 분석 Tool
다음은 각 OS에서 사용하는 분석 툴입니다.
분석을 위해서는 statck분석 툴과 map분석 툴을 사용합니다.
    Solaris:
        stack 명령 = pstack
        map 명령 = pmap
    IBM의 추가 기능이 있는 AIX 5.2 이상(이전 버전에서는 사용할 수 없음)
        stack 명령 = procstack
        map 명령 = procmap
        참고: http://www-106.ibm.com/developerworks/eserver/articles/AIX5.2PerfTools.html
 
    Linux:
        stack = lsstack
        map = pmap
 
참고: http://sourceforge.net/projects/lsstack/에서 lsstack을 가져와서 Linux 플랫폼에서 빌드할 수 있습니다.
이 명령은 Solaris의 pstack에 해당합니다.
 
http://web.hexapodia.org/~adi/pmap.c에서 pmap 소스를 가져와서 Linux 플랫폼에서 빌드할 수 있습니다.
 
HPUX: 기본 제공 툴은 없으며, GDB, ADB을 사용함.
 
명령어 사용
 
각 명령어의 보다 자세한 옵션 사항은 명령어의 Help을 참조하십시오.
 
Solaris 예
 
/usr/bin/pstack [-F] [pid | core] > [분석내용저장파일명]
 
ex) pstack core2004-10-29 > coreStack.txt
 
/usr/bin/pmap [ -rslF ]  [ pid | core ] > [분석내용저장파일명]
 
Ex) pmap core2004-10-29 > coreMap.txt
 
 
분석
 
coreStack.txt 내용
core 'core' of 20956:   /wwsl/sharedInstalls/solaris/wls70sp2/jdk131_06/bin/../bin/sparc/nativ
-----------------  lwp# 14 / thread# 25  --------------------
 ff369764 __sigprocmask (ff36bf60, 0, 0, e6181d70, ff37e000, 0) + 8
 ff35e110 _sigon   (e6181d70, ff385930, 6, e6180114, e6181d70, 6) + d0
 ff361150 _thrp_kill (0, 19, 6, ff37e000, 19, ff2c0450) + f8
 ff24b900 raise    (6, 0, 0, ffffffff, ff2c03bc, 4) + 40
 ff2358ec abort    (ff2bc000, e6180268, 0, fffffff8, 4, e6180289) + 100
 fe3c68fc __1cCosFabort6Fl_v_ (1, fe4c8000, 1, e61802e8, 0, e9f90420) + b8
 fe3c59f0 __1cCosbBhandle_unexpected_exception6FpnGThread_ipCpv_v_ (ff2c02ac, fe53895c, fe4dc164, fe470ab4, fe4c8000, e6180308) + 254
 fe20a8b4 JVM_handle_solaris_signal (0, 25d5b8, e6180d90, fe4c8000, b, e6181048) + 8ec
 ff36b824 __sighndlr (b, e6181048, e6180d90, fe20a8cc, e6181e14, e6181e04) + c
 ff3684d8 sigacthandler (b, e6181d70, 0, 0, 0, ff37e000) + 708
 --- called from signal handler with signal 11 (SIGSEGV) ---
 e9f90420 Java_HelloWorld_displayHelloWorld (25d644, e6181224, e61819b8, 0, 2, 0) + 30
 00090ae4 ???????? (e6181224, e61819b8, 25d5b8, fe4c8000, 0, 109a0)
 0008dc4c ???????? (e61812c4, ffffffff, ffffffff, 97400, 4, e61811b8)
 0008dc4c ???????? (e618135c, e61819b8, fe4c8000, 99600, c, e6181250)
 0008dc4c ???????? (e61813ec, f76a2f90, e618147c, 99600, c, e61812f8)
 0008ddb4 ???????? (e618147c, f68578b8, 0, 99974, c, e6181388)
 0008ddd8 ???????? (e618154c, e61815c8, e61815cc, 99974, 4, e6181410)

 
굵은 부분이 오류가 발생한 부분을 나타낸다. “--- called from signal handler with signal“을 찾으면 된다. 이 오류가 발생한 메모리 영역이 “e9f90420“ 이다. coreMap.txt 파일에서 이 주소값이 포함되는 범위를 찾아본다.
 
coreMap.txt 내용
E9500000   1184K read
E9680000   1392K read
E9800000   4608K read
E9F60000    136K read/write/exec
E9F90000      8K read/exec         /home/usera/wls70/solaris/projectWork/lib/libhello.so
E9FA0000      8K read/write/exec   /home/usera/wls70/solaris/projectWork/lib/libhello.so
E9FB4000      8K read/write/exec
E9FC0000    120K read/exec         /usr/lib/libelf.so.1
E9FEE000      8K read/write/exec   /usr/lib/libelf.so.1

 
“e9f90420“ 가 포함된 범위에서 사용되는 라이블러리는 “libhello.so“ 임을 알 수 있다.
Core 발생은 주 원인은 “libhello.so“ 일 가능성으로 추측할 수 있다.