확인 충돌 * .LOG 및 GDB

업데이트 내가 바로 코어 파일을 얻을 수 있었다확인 충돌 * .LOG 및 GDB

2011 년 9 월 12 추락 지시를 dissabled. 조언에 따라 나는 r28의 가치를 추적했다 (그런데 레지스트리 엔트리가 hs_err_pid * .log에 로그가되지 않았다). 그리고 그 값이 어디서 왔는지 확인한다. (아래 참조/< ---). 그러나, 나는 r32의 가치를 결정할 수 없었다.

정렬이 잘못 된 이유는 r28이 4 바이트 정수 r31에로드 된 8 바이트 정수라는 이유 때문입니까?

;;; 1053    if(Transfer(len) == FALSE) { 
0xc00000000c0c55c0:2 <TFM::PrintTrace(..)+0x32>:  adds   r44=0x480,r32;; <--- 
0xc00000000c0c55d0:0 <TFM::PrintTrace(..)+0x40>:  ld8   r43=[ret2] 
0xc00000000c0c55d0:1 <TFM::PrintTrace(..)+0x41>: (p6) st4   [r35]=ret3 
0xc00000000c0c55d0:2 <TFM::PrintTrace(..)+0x42>:  adds   r48=28,r33 
0xc00000000c0c55e0:0 <TFM::PrintTrace(..)+0x50>:  mov   ret0=0;; 
0xc00000000c0c55e0:1 <TFM::PrintTrace(..)+0x51>:  ld8.c.clr r62=[r45] 
0xc00000000c0c55e0:2 <TFM::PrintTrace(..)+0x52>:  cmp.eq.unc p6,p1=r0,r62 
;;; 1056      throw MutexLock ; 
0xc00000000c0c55f0:0 <TFM::PrintTrace(..)+0x60>:  nop.m  0x0 
0xc00000000c0c55f0:1 <TFM::PrintTrace(..)+0x61>:  nop.m  0x0 
0xc00000000c0c55f0:2 <TFM::PrintTrace(..)+0x62>: (p6) br.cond.dpnt.many _NZ10TFM07PrintTraceEPi+0x800;; 
;;; 1057    } 
0xc00000000c0c5600:0 <TFM::PrintTrace(..)+0x70>:  adds   r41=0x488,r32 
0xc00000000c0c5600:1 <TFM::PrintTrace(..)+0x71>:  adds   r40=0x490,r32 
0xc00000000c0c5600:2 <TFM::PrintTrace(..)+0x72>:  br.call.dptk.many rp=0xc00000000c080620;; 
;;; 1060    dwDataLen = len ; 
0xc00000000c0c5610:0 <TFM::PrintTrace(..)+0x80>:  ld8   r16=[r44] <--- 
0xc00000000c0c5610:1 <TFM::PrintTrace(..)+0x81>:  mov   gp=r36 
0xc00000000c0c5610:2 <TFM::PrintTrace(..)+0x82>: (p1) mov   r62=8;; 
0xc00000000c0c5620:0 <TFM::PrintTrace(..)+0x90>:  cmp.eq.unc p6=r0,r16 
0xc00000000c0c5620:1 <TFM::PrintTrace(..)+0x91>:  nop.m  0x0 
0xc00000000c0c5620:2 <TFM::PrintTrace(..)+0x92>: (p6) br.cond.dpnt.many _NZ10TFM07PrintTraceEPi+0xda0;; 
0xc00000000c0c5630:0 <TFM::PrintTrace(..)+0xa0>:  adds   r21=16,r16 <--- 
0xc00000000c0c5630:1 <TFM::PrintTrace(..)+0xa1>: (p1) mov   r62=8;; 
0xc00000000c0c5630:2 <TFM::PrintTrace(..)+0xa2>:  nop.i  0x0 
0xc00000000c0c5640:0 <TFM::PrintTrace(..)+0xb0>:  ld8   r42=[r21];; <--- 
0xc00000000c0c5640:1 <TFM::PrintTrace(..)+0xb1>:  cmp.eq.unc p6=r0,r42 
0xc00000000c0c5640:2 <TFM::PrintTrace(..)+0xb2>:  nop.i  0x0 
0xc00000000c0c5650:0 <TFM::PrintTrace(..)+0xc0>:  nop.m  0x0 
0xc00000000c0c5650:1 <TFM::PrintTrace(..)+0xc1>:  mov   r47=5 
0xc00000000c0c5650:2 <TFM::PrintTrace(..)+0xc2>: (p6) br.cond.dpnt.many _NZ10TFM07PrintTraceEPi+0xdf0;; 
0xc00000000c0c5660:0 <TFM::PrintTrace(..)+0xd0>:  ld4.a  r27=[r48] 
;;; 1064      if(dwDataLen <= dwViewLen) { 
0xc00000000c0c5660:1 <TFM::PrintTrace(..)+0xd1>:  adds   r28=28,r42 <-- 
0xc00000000c0c5660:2 <TFM::PrintTrace(..)+0xd2>:  cmp.ne.unc p6=r0,r46;; 
0xc00000000c0c5670:0 <TFM::PrintTrace(..)+0xe0>:  ld4.sa  r26=[r28], 
0xc00000000c0c5670:1 <TFM::PrintTrace(..)+0xe1>: (p6) ld4   r31=[r28] <-- instruction that crashed

레지스터 값이 필요한지 알려주세요. gdb의 info reg 명령을 사용하여 레지스터 값을 얻을 수 있다고 생각합니다. 이것은 정보 레지스터 (prXXX 및 brXXX의 값 제외)의 결과입니다. 위의 디스 어셈블 된 명령어에 매핑하는 방법을 알지 못합니다.

gr1: 0x9fffffffbf716588 
    gr2: 0x9fffffff5f667c00 
    gr3: 0x9fffffff5f667c00 
    gr4: 0x6000000000e0b000 
    gr5: 0x9fffffff8adfe2e0 
    gr6: 0x9fffffff8ada9000 
    gr7: 0x9fffffff8ad7a000 
    gr8:    0x1 
    gr9: 0x9fffffff8adfd0f0 
gr10:     0 
gr11: 0xc000000000000690 
gr12: 0x9fffffff8adfd140 
gr13: 0x6000000001681510 
gr14: 0x9fffffffbf7d8e98 
gr15:    0x1a 
gr16: 0x60000000044dac60 
gr17:    0x1f 
gr18:     0 
gr19: 0x9fffffff8ad023f0 
gr20: 0x9fffffff8adfd0e0 
gr21: 0x60000000044dac70 
gr22: 0x9fffffff5f668000 
gr23:    0xd 
gr24:    0x1 
gr25: 0xc0000000004341f0 
gr26:    NaT 
gr27:    0x63 
gr28: 0xc00000000c5f801c 
gr29: 0xc00000000029db20 
gr30: 0xc00000000029db20 
gr31:    0x288 
gr32: 0x60000000044796d0 
gr33: 0x6000000001a78910 
gr34:    0x7e 
gr35: 0x6000000001d03a90 
gr36: 0x9fffffffbf716588 
gr37: 0xc000000000000c9d 
gr38: 0xc00000000c0c4f70 
gr39:    0x9 
gr40: 0x6000000004479b60 
gr41: 0x6000000004479b58 
gr42: 0xc00000000c5f8000 
gr43: 0x9fffffffbf7144e0 
gr44: 0x6000000004479b50 
gr45: 0x6000000004479b68 
gr46: 0x6000000001d03a90 
gr47:    0x5 
gr48: 0x6000000001a7892c 
gr49: 0x9fffffff8adfe110 
gr50: 0xc000000000000491 
gr51: 0xc00000000c0c5520 
gr52: 0xc00000000c07dd10 
gr53: 0x9fffffff8adfe120 
gr54: 0x9fffffff8adfe0a0 
gr55: 0xc00000000000058e 
gr56: 0xc00000000042be40 
gr57:    0x39 
gr58:    0x3 
gr59:    0x33 
gr60:     0 
gr61: 0x9fffffffbf7d2598 
gr62:    0x8 
gr63: 0x9fffffffbf716588 
gr64: 0xc000000000000f22 
gr65: 0xc00000000c0c5610

이 내 이전 게시물에 대한 업데이트입니다. I 코어 파일의 복사본 을 구비하고 있기 때문에, I 코어 파일을 검사 GDB를 사용 에게 다음 명령 실행 :

BT는

2) 프레임 N < - 강제 종료가 발생한 프레임

3) disas

그리고 결과는 다음과 같습니다. (이 경우 strstr) 함수로부터의 오프셋 (offset)

C [libc.so.6+0x88368] strstr+0x64a

주 작은 충돌 지점 :

(gdb) bt 
#0 0xc0000000001e5350:0 in _lwp_kill+0x30() 
    from /usr/lib/hpux64/libpthread.so.1 
#1 0xc00000000014c7b0:0 in pthread_kill+0x9d0() 
    from /usr/lib/hpux64/libpthread.so.1 
#2 0xc0000000002e4080:0 in raise+0xe0() from /usr/lib/hpux64/libc.so.1 
#3 0xc0000000003f47f0:0 in abort+0x170() from /usr/lib/hpux64/libc.so.1 
#4 0xc00000000e65e0d0:0 in os::abort() 
    at /CLO/Components/JAVA_HOTSPOT/Src/src/os/hp-ux/vm/os_hp-ux.cpp:2033 
#5 0xc00000000eb473e0:0 in VMError::report_and_die() 
    at /CLO/Components/JAVA_HOTSPOT/Src/src/share/vm/utilities/vmError.cpp:1008 
#6 0xc00000000e66fc90:0 in os::Hpux::JVM_handle_hpux_signal() 
    at /CLO/Components/JAVA_HOTSPOT/Src/src/os_cpu/hp-ux_ia64/vm/os_hp-ux_ia64.cpp:1051 
#7 <signal handler called> 
#8 0xc00000000c0c5670:1 in TFMTrace::PrintTrace() at tfmtrace.cpp:1064 
#9 0xc00000000c0c4f70:0 in FMLogger::WriteLog() at fmlogger.cpp:90 
... 

(gdb) frame 8 
#8 0xc00000000c0c5670:1 in TFMTrace::PrintTrace() at tfmtrace.cpp:1064 
1064       if(dwDataLen <= dwViewLen) { 
Current language: auto; currently c++ 

(gdb) disas $pc-16*4 $pc+16*4 
... 
0xc00000000c0c5660:0 <TFMTrace::PrintTrace(...)+0xd0> :  ld4.a  r27=[r48]  MII, 
;;; 1064    if(dwDataLen <= dwViewLen) { 
0xc00000000c0c5660:1 <TFMTrace::PrintTrace(...)+0xd1> :  adds   r28=28,r42 
0xc00000000c0c5660:2 <TFMTrace::PrintTrace(...)+0xd2> :  cmp.ne.unc p6=r0,r46;; 
0xc00000000c0c5670:0 <TFMTrace::PrintTrace(...)+0xe0> :  ld4.sa  r26=[r28]  MMI, 
0xc00000000c0c5670:1 <TFMTrace::PrintTrace(...)+0xe1> : (p6) ld4   r31=[r28] 
0xc00000000c0c5670:2 <TFMTrace::PrintTrace(...)+0xe2> :  adds   r46=24,r42;; 
0xc00000000c0c5680:0 <TFMTrace::PrintTrace(...)+0xf0> : (p6) st4  [r35]=r31   MI,I 
0xc00000000c0c5680:1 <TFMTrace::PrintTrace(...)+0xf1> :  adds   r59=36,r42;; 
0xc00000000c0c5680:2 <TFMTrace::PrintTrace(...)+0xf2> :  nop.i   0x0 
0xc00000000c0c5690:0 <TFMTrace::PrintTrace(...)+0x100>:  ld4.c.clr r27=[r48]  MIB, 
;;; 1066    dwLen = dwTrcLen ; 
0xc00000000c0c5690:1 <TFMTrace::PrintTrace(...)+0x101>:  cmp4.eq.unc p6,p8=99,r27 
0xc00000000c0c5690:2 <TFMTrace::PrintTrace(...)+0x102>:  nop.b   0x0;; 
0xc00000000c0c56a0:0 <TFMTrace::PrintTrace(...)+0x110>: (p8) ld4.c.clr r26=[r28]  MMI 
;;; 1067    } 
0xc00000000c0c56a0:1 <TFMTrace::PrintTrace(...)+0x111>: (p6) st4  [r48]=r47 
0xc00000000c0c56a0:2 <TFMTrace::PrintTrace(...)+0x112>:  cmp4.geu.unc p7=r26,r27 
End of assemb

출처

2011-08-02 ryanb

네이티브 코드에서 "정상"충돌이 같은 보고서가 발생합니다. 귀하의 경우에는

는, JVM은 주소 oxc00000000f675671 내부 libtracejni.so 것을 결정하지만, 찾을 수있는 가장 가까운 기능은 매우까지 충돌 지점 (멀리 0x5065eff9 == 1.2 GB)에서 입니다.

라이브러리가 실제로 그렇게 큰가요?

정말 큰 경우, 코드를 제거했을 가능성이 있으며 따라서 _NZ10TFM07PrintTraceEPi 기호는 실제로 문제 (1.2GB 거리의 코드)와 관련이 없습니다.

충돌했을 때 실제로 주소가 oxc00000000f675671 인 코드를 찾아야합니다. 일반적으로 hs_err_pid*.log에는 모든 공유 라이브러리에 대한로드 주소 목록이 들어 있습니다. 로드 주소가 libtracejni.so 인 것을 찾아 pc에서 뺍니다. 그러면 libtracejni.so의 스트라이핑되지 않은 버전에서 조회 할 수 있어야하는 0x400...675671과 유사한 주소를 제공해야합니다.

또한 충돌 주소는 ASCII "C8G"으로 끝나며 우연 일 수도 있고 아닐 수도 있습니다.

업데이트 2011/08/05

이제 추락하는지도 알고

0x4000000000099670:1 <TFMTrace::PrintTrace(...)+0xe1>: (p6) ld4 r31=[r28]

이 r28가 가리키는 메모리에서 4 바이트 정수의 부하입니다.

다음 질문은 충돌 지점에서 r28의 값 (hs_err * .log에 로그인해야 함)과 어디에서 왔는지 (TFM::PrintTrace의 완전한 디스 어셈블리가이를 알려줍니다)입니다.

출처

2011-08-02 23:52:07

원본 게시물의 후속 조치를 참조하십시오. 라이브러리의 크기는 ** 2.1MB **입니다. – ryanb

9 월 12 일 업데이트를 참조하십시오. 핵심 파일을 가져올 수있었습니다. – ryanb

확인 충돌 * .LOG 및 GDB

답변

관련 문제