JVM Fatal error log (Hs_err_pid.log) interpretation

When a fatal error occurs, the JVM generates a file such as Hs_err_pid<pid>.log, which often contains important information about the cause of the virtual machine crash. Since often encountered, in this article, I picked one, and analyzed the contents of it each paragraph (files can be downloaded at the end of the article). By default, files are created in the working directory (the JVM attempts to write files to a temporary directory such as/tmp if no permissions are created), and of course, the file format and path can also be specified by parameters such as: Java-xx:errorfile=/var/log/java/java_error%p.log This file will include: An operation exception or signal that triggers a fatal error; Version and configuration information; Thread details and line stacks that trigger a fatal exception; The list of currently running threads and their status; Aggregate information of the heap; the loaded local library; command-line arguments; environment variables; Detailed information about the operating system CPU. First, you see a brief overview of the problem: # SIGSEGV (0XB) at PC=0X03568CF4, pid=16819, tid=3073346448 An unintended error was detected by the JRE, where: SIGSEGV is the signal name 0XB is the letter number PC=0X03568CF4 refers to the value of the program counter pid=16819 is the process number tid=3073346448 is the thread number If you have a knowledge of the JVM, you should not be unfamiliar with these things. Next is the version information for the JRE and JVM: # JRE Version:6.0_32-b05 # Java Vm:java HotSpot (TM) Server VM (20.7-b02 mixed Mode linux-x86) Run in mixed mode. Then the information for the problem frame: # Problematic Frame: # C [LIBGTK-X11-2.0.SO.0+0X19FCF4] __float128+0x19fcf4 C: The frame type is a local frame, and the type of the frame includes: C: local C-Frame J: Explanation of the Java frame V: Virtual Machine frame V: Stub stack frame generated by virtual machine J: Other frame types, including compiled Java frames LIBGTK-X11-2.0.SO.0+0X19FCF4: The same as the program counter (PC), but with the local so library + offset method. Then the first part is the thread information: Current thread (0X09F30C00): Javathread "Main" [_thread_in_native, id=16822, Stack (0xb72a8000,0xb72f9000)] of the current thread: 0X09F30C00: pointer Javathread: Thread types, possible types include: Javathread Vmthread Compilerthread Gctaskthread Watcherthread Concurrentmarksweepthread Main: Name _thread_in_native: Thread Current state, state enumeration includes: _thread_uninitialized: The thread has not been created, it only appears when memory causes crash _thread_new: Thread has been created, but not yet started _thread_in_native: The thread is executing local code, which is most likely a problem with local code _THREAD_IN_VM: Thread is executing virtual machine code _thread_in_java: Thread is executing an explanation or compiled Java code _thread_blocked: Thread is in a blocked state _trans: End With _trans, the thread is in the middle state to switch to another State ID=16822: Thread ID 0xb72a8000,0xb72f9000: Stack interval Siginfo:si_signo=sigsegv:si_errno=0, Si_code=1 (segv_maperr), si_addr=0x00000010 This is part of the unexpected signal information that causes the virtual machine to terminate, meaning it has been roughly mentioned before. Where Si_errno and Si_code are used to identify anomalies under Linux, Windows is a exceptioncode. eax=0x00000000, ebx=0x0375dd84, ecx=0x00000000, edx=0x00000000 esp=0xb72f0fa0, Ebp=0xb72f0fb8, ESI=0x00000000, EDI= 0x0a6c1800 eip=0x03568cf4, eflags=0x00010246, cr2=0x00000010 This is the register context. Top of Stack: (sp=0xb72f0fa0) 0xb72f0fa0:00000000 00402250 0040217f 0375dd84 0xb72f0fb0:00000000 0a6c1800 B72f0fe8 0   356c2c0 0xb72f0fc0:00000000 0a6c1800 b72f0fe8 003b3e77 0xb72f0fd0:003e6c8b 0a1a70d0 0a193358 0375dd84 0xb72f0fe0: 0a276418 0a276418 b72f1048 03536c56 0xb72f0ff0:0acad000 0b3ca978 0000000c 00dd0674 0xb72f1000:00000003 0A2C7D50 b72f 1038 0000330c 0xb72f1010:ffffffff ffffffff 00000001 00000001 Instructions: (PC=0X03568CF4) 0x03568cd4:89 14 24 89 75 F8 d6 7d FC C7 E8 7e 1b 0x03568ce4:ea FF d4 89 E8 (EA FF 0x03568cf4:8b 40 10) 3c C7 (0X03568D04:D0) (8b), the E8 DD, which is in the same The opcode next to the stack Top program counter, which can be disassembled into instructions executed before the system crashes. Register to Memory mapping:eax=0x00000000 are an unknown value ebx=0x0375dd84: <offset 0x394d84> in/usr/lib/libgtk- x11-2.0.so.0 at 0x033c9000 ecx=0x00000000 are an unknown value edx=0x00000000 are an unknown value esp=0xb72f0fa0 is Pointin G into the stack for thread:0x09f30c00 Ebp=0xb72f0fb8 are pointing into the stacks for thread:0x09f30c00 esi=0x00000000 are An unknown value edi=0x0a6c1800 was an unknown value Register and Memory mapping information. Stack: [0xb72a8000,0xb72f9000],  sp=0xb72f0fa0,  free space=291k Native Frames: (J=compiled Java Code, j=interpreted, VV=VM Code, c=native code) c  [libgtk-x11-2.0.so.0+0x19fcf4]  __float128+ 0X19FCF4 c  [libgtk-x11-2.0.so.0+0x1a32c0]  __float128+0xc0 ... C&NBSP;&NBSP;[LIBSWT-PI-GTK-3738.SO+0X33F6A]&NBSP;&NBSP;JAVA_ORG_ECLIPSE_SWT_INTERNAL_GTK_OS__1CALL+0XF J   org.eclipse.swt.internal.gtk.os._call (iii) I J  org.eclipse.swt.internal.gtk.os.call (iii) I Java Frames: (j=compiled Java Code, j=interpreted, VV=VM Code) j  org.eclipse.swt.internal.gtk.os._call (III) I J& Nbsp; org.eclipse.swt.internal.gtk.os.call (III) I j   Org.eclipse.swt.widgets.Widget.fixedSizeAllocateProc (II) i+5 j   Org.eclipse.swt.widgets.Display.fixedSizeAllocateProc (II) i+17 v  ~stubroutines::call_stub Line Stacks. Contains the address, stack top, stack counter and thread unused stack information, because the stack may be very long, the length of the print is limited, but at least the local stack and the Java stack are printed (many times the local stack can not print, but the Java stack is usually printed out). As you can see, Eclipse's virtual machine crashes. Ava Threads: (= = current thread) 0x0b4c1000 javathread "Worker-247" [_thread_blocked, id=25417, Stack (0x741bc000,0x 7420d000)] 0x0a300c00 javathread "Worker-246" [_thread_blocked, id=25235, Stack (0x7d30c000,0x7d35d000)] ... Thread information. At a glance, not explained. VM State:not at SafePoint (normal execution) The virtual machine state. Including: Not at a safepoint: normal operating State; At SafePoint: All threads are blocked by the virtual machine wait state, waiting for a virtual machine operation to complete; Synchronizing: A special virtual machine operation that requires other threads within the virtual machine to remain in a wait state. VM Mutex/monitor currently owned by a Thread:none The virtual machine's mutex and monitor are not currently held by threads. A mutex is a lock inside a virtual machine, and monitor is associated with a Java object. Heap Psyounggen Total 149056K, used 125317K [0xa9700000, 0xb41a0000, 0xb41a0000) Eden Space 123520K, 95% used [0xa 9700000,0xb0ac0de0,0xb0fa0000) from space 25536K, 26% used [0xb28b0000,0xb2f50748,0xb41a0000] to space 25600K, 0% us   Ed [0xb0fa0000,0xb0fa0000,0xb28a0000] Psoldgen total 261248K, used 239964K [0x941a0000, 0xa40c0000, 0xa9700000) Object Space 261248K, 91% used [0x941a0000,0xa2bf7018,0xa40c0000) Pspermgen total 163328K, used 130819K [0x841a0000 , 0x8e120000, 0x941a0000) object space 163328K, 80% used [0x841a0000,0x8c160c40,0x8e120000] Heap information. New generation, Laosheng generation, permanent generation. Those who know about the JVM should be clear and do not explain. Code Cache [0xb4262000, 0xb5ac2000, 0xb7262000) total_blobs=5795 nmethods=5534 adapters=209 free_code_cache=25103616 LA rgest_free_block=38336 Code cache. This is a piece of memory for compiling and saving local code, note that it is local code, it is not the same as PermGen (permanent generation), and the permanent band is used to store the Java class definition. Dynamic libraries:00101000-00122000 R-xp 00000000 08:01 3483560/usr/lib/libjpeg.so.62.0.0 00122000-00123000 rwxp 0002 0000 08:01 3483560/usr/lib/libjpeg.so.62.0.0 00125000-00130000 R-xp 00000000 08:01 9093202/lib/libgcc_s-4.1.2-2008 0825.so.1 00130000-00131000 rwxp 0000a000 08:01 9093202/lib/libgcc_s-4.1.2-20080825.so.1 ... Memory-mapped. This information is the virtual memory list area when the virtual machine crashes. When locating the cause of the crash, it can tell you which libraries are being used, where they are located, and the stack and Guardian page information. Take the first article in the list as an example: 00101000-00122000: Memory Area R-XP: Permissions, r/w/x/p/s respectively read/write/execute/private/shared 00000000: Offset within the file 08:01: Majorid and Minorid of file locations 3483560: Index Node number /usr/lib/libjpeg.so.62.0.0: File location Each lib has two pieces of virtual memory area-code and data, their permissions are different, the code area is r-xp; The data area is RWXP. The Guard page is comprised of a pair of--XP and RWXP permissions. VM Arguments:jvm_args:-dosgi.requiredjavaversion=1.5-xx:maxpermsize=256m-xms40m-xmx512m- Dorg.eclipse.swt.browser.xulrunnerpath= ' Java_command:/.../eclipse/plugins/org.eclipse.equinox.launcher_1.2.0. V20110502.jar-os linux-ws gtk-arch x86-showsplash-launcher/.../eclipse/eclipse-name eclipse ... Launcher Type:sun_standard Environment variables:path= ... display=:0.0 Virtual machine parameters and environment variables. Signal HANDLERS:SIGSEGV: [libjvm.so+0x726440], Sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 sigbus: [libjvm.so+ 0X726440], Sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 ... The signal handle. For the signaling mechanism under Linux, see Wiki wikipedia, links . os:red Hat Enterprise Linux Client Release 5.4 (Tikanga) uname650) this.width=650; "border=" 0 "src=" http://techfoxbbs.com /static/image/smiley/default/sweat.gif "/>inux 2.6.18-164.el5 #1 SMP Tue-15:51:54 EDT i686 LIBC:GLIBC 2.5 N PTL 2.5 rlimit:stack 10240k, CORE 0k, Nproc 65536, Nofile 1024x768, as Infinity load average:1.78 1.58 1.54/proc/meminfo:.. . Cpu:total 4 (4 cores per CPU, 1 threads per core) Family 6 model stepping 7, Cmov, cx8, FXSR, MMX, SSE, SSE2, SSE3, SSS E3/proc/cpuinfo: ... memory:4k page, physical 3631860k (155144k free), swap 5124724k (5056452k free)

More Java http://techfoxbbs.com

This article is from the "Wu Fanxin blog" blog, make sure to keep this source http://melorogee.blog.51cto.com/6909056/1629709

JVM Fatal error log (Hs_err_pid.log) interpretation