JVM crash log information analysis

From: http://www.cnblogs.com/shiyangxt/archive/2009/01/06/1370627.html thanks to the author Shi Yang

A jvm crash error was reported during JNI the other day. The error message is as follows:

#
# An Unexpected error has been detected by hotspot virtual machine:
#
# Exception_access_violation (0xc0000005) at PC = 0x009fcf52, pid = 4752, tid = 4440
#
# Java VM: Java hotspot (TM) Client VM (1.5.0 _ 14-b03 Mixed Mode)
# Problematic frame:
# V [JVM. dll + 0x9cf52]
#
# An error report file with more information is saved as hs_err_pid4752.log
#
# If you wowould like to submit a bug report, please visit:
# Http://java.sun.com/webapps/bugreport/crash.jsp
#
I just want to generate a Java date object through C ++ and then output the current time. What we can probably know through this error message is:

The JVM crash is finished, and the error hs_err_pid4752.log is output.

Bytes ----------------------------------------------------------------------------------------------------

This error is reported when the result is running, and a log error log is generated. In fact, one error is generated at a time. I only give one of them:

To prevent local information leakage, I dropped the path screen.

#
# An Unexpected error has been detected by hotspot virtual machine:
#
# Exception_access_violation (0xc0000005) at PC = 0x009fcf52, pid = 4344, tid = 5876
#
# Java VM: Java hotspot (TM) Client VM (1.5.0 _ 14-b03 Mixed Mode)
# Problematic frame:
# V [JVM. dll + 0x9cf52]
#

--------------- T h r e a d ---------------

Current thread (0x00823d30): javathread "Main" [_ thread_in_vm, id = 5876]

Siginfo: exceptioncode = 0xc0000005, reading address 0x00000000

Registers:
Eax = 0x00000000, EBX = 0x06f8c0f8, ECx = 0x0006f954, EDX = 0x00823df0
ESP = 0x0006f934, EBP = 0x0006f980, ESI = 0x0006f954, EDI = 0x0006f9e8
EIP = 0x009fcf52, eflags = 0x00010246

Top of Stack: (sp = 0x0006f934)
0x0006f934: 009eb893 00000000 00823d30 009ecac3
0x0006f944: 00823d30 00000000 0006f9fc 0006f998
0x0006f954: 00823df0 0082b438 009a1e20 00823d30
0x0006f964: 0006f980 009ebb6a 00823d30 0000000e
0x0006f974: 00000004 0006f9e8 0006f998 0006f9e8
0x0006f984: 1000148b 00823df0 0082b434 00000000
0x0006f994: 0006f9fc 0006fa5c 06f8c0f8 06f8c0f8
0x0006f9a4: cccccccc

Instructions: (Pc = 0x009fcf52)
0x009fcf42: 44 24 04 24 FC 8B 00 8B 00 C3 8B 44 24 04 24 FC
0x009fcf52: 8B 00 FF 74 24 04 8B C8 E8 93 Fe FF C3 8B 44

STACK: [0x00030000,0x00070000), SP = 0x0006f934, free space = 254 K
Native frames: (j = compiled Java code, j = interpreted, VV = VM code, c = native code)
V [JVM. dll + 0x9cf52]
C [nativecode. dll + 0x148b]
C [nativecode. dll + 0x1253]
J com. Sy. Test. testnative. sayhello () V + 0
J com. Sy. Test. testnative. Main ([ljava/lang/string;) V + 22
V ~ Stubroutines: call_stub
V [JVM. dll + 0x875dd]
V [JVM. dll + 0xdfd96]
V [JVM. dll + 0x874ae]
V [JVM. dll + 0x8e6f1]
C producer javaw.exe + 0x14c5]
C producer javaw.exe + 0x3151]
C [kernel32.dll + 0x16fd7]

Java frames: (j = compiled Java code, j = interpreted, VV = VM code)
J com. Sy. Test. testnative. sayhello () V + 0
J com. Sy. Test. testnative. Main ([ljava/lang/string;) V + 22
V ~ Stubroutines: call_stub

--------------- P r o c e s ---------------

Java threads: (=> current thread)
0x008306d0 javathread "low memory detector" daemon [_ thread_blocked, id = 5624]
0x0082fb30 javathread "compilerthread0" daemon [_ thread_blocked, id = 5988]
0x0082e8c0 javathread "signal dispatcher" daemon [_ thread_blocked, id = 2400]
0x0082de70 javathread "finalizer" daemon [_ thread_blocked, id = 5704]
0x0082ccf0 javathread "reference handler" daemon [_ thread_blocked, id = 4240]
=> 0x00823d30 javathread "Main" [_ thread_in_vm, id = 5876]

Other threads:
0x0082a060 vmthread [ID = 1960]
0x00831270 watcherthread [ID = 5708]

VM state: Not at safepoint (normal execution)

VM mutex/monitor currently owned by a thread: None

Heap
Def New Generation total 576 K, used 209 K [0x02de0000, 0x02e80000, 0x032c0000)
Eden space 512 K, 40% used [0x02de0000, 0x02e14510, 0x02e60000)
From space 64 K, 0% used [0x02e60000, 0x02e60000, 0x02e70000)
To space 64 K, 0% used [0x02e70000, 0x02e70000, 0x02e80000)
Tenured generation total 1408 K, used 0 K [0x032c0000, 0x03420000, 0x06de0000)
The space 1408 K, 0% used [0x032c0000, 0x032c0000, 0x032c0200, 0x03420000)
Compacting perm Gen total 8192 K, used 1715 K [0x06de0000, 0x075e0000, 0x0ade0000)
The space 8192 K, 20% used [0x06de0000, 0x06f8cdb0, 0x06f8ce00, 0x075e0000)
No shared spaces configured.

Dynamic libraries:
0x00400000-0x0040d000 *******************************

0x7c920000-0x7c9b4000 c: \ windows \ system32 \ NTDLL. dll
0x7c800000-0x7c91d000 c: \ windows \ system32 \ kernel32.dll
0x77da0000-0x77e49000 c: \ windows \ system32 \ advapi32.dll
0x77e50000-0x77ee2000 c: \ windows \ system32 \ rpcrt4.dll
0x77fc0000-0x77fd1000 c: \ windows \ system32 \ secur32.dll
0x77d10000-0x77d9f000 c: \ windows \ system32 \ user32.dll
0x77ef0000-0x77f38000 c: \ windows \ system32 \ gdi32.dll
0x77be0000-0x77c38000 c: \ windows \ system32 \ msvcrt. dll
0x76300000-0x7631d000 c: \ windows \ system32 \ imm32.dll
0x62c20000-0x62c29000 c: \ windows \ system32 \ LPK. dll
0x73fa0000-0x7400b000 c: \ windows \ system32 \ usp10.dll
0x6d710000-0x6d723000 c: \ progra ~ 1 \ Kasper ~ 1 \ Kasper ~ 1 \ mzvkbd. dll
0x76bc0000-0x76bcb000 c: \ windows \ system32 \ psapi. dll
0x6d730000-0x6d743000 c: \ progra ~ 1 \ Kasper ~ 1 \ Kasper ~ 1 \ mzvkbd3.dll
0x6d020000-0x6d035000 c: \ progra ~ 1 \ Kasper ~ 1 \ Kasper ~ 1 \ adialhk. dll
0x77f40000-0x77fb6000 c: \ windows \ system32 \ shlwapi. dll
0x6d4c0000-0x6d4c6000 c: \ progra ~ 1 \ Kasper ~ 1 \ Kasper ~ 1 \ kloehk. dll
0x00960000-0x00afe000 *******************************

0x76b10000-0x76b3a000 c: \ windows \ system32 \ winmm. dll
0x6d290000-0x6d298000 *******************************

0x6d610000-0x6d61c000 *******************************

0x6d310000-0x6d32d000 *******************************

0x6d630000-0x6d63f000 *******************************

0x10000000-0x1004e000 *******************************

VM arguments:
Java_command: COM. Sy. Test. testnative
Launcher type: sun_standard

Environment variables:
Java_home = *******************************

Classpath = *******************************
Path = *******************************
Username = user
OS = windows_nt
Processor_identifier = x86 family 6 model 14 stepping 8, genuineintel

--------------- S y s t e m ---------------

OS: Windows XP build 2600 Service Pack 2

CPU: Total 1 (cores per CPU 1, threads per core 1) family 6 model 14 stepping 8, cmov, cx8, fxsr, MMX, SSE, sse2

Memory: 4 K page, physical 1300464 K (465904 K free), swap 3092560 K (2157304 K free)

Vm_info: Java hotspot (TM) Client VM (1.5.0 _ 14-b03) for windows-x86, built on Oct 5 2007 01:21:52 by "java_re" with ms vc ++ 6.0

After seeing some error logs, we can conclude that an error occurred when I used the Java main function to call the local DLL file.

I preliminarily inferred that my c ++ didn't recycle the Java object after it was passed to the Java class. Memory leakage.

However, I am a beginner, so I am not familiar with C ++'s control of Java. Therefore, after debugging, C ++ cannot compile and translate. Due to recent exam stress

It's too big. It forces me to put this problem down for the moment.

But I am not happy with it, so I started searching for a long period of information retrieval.

Discover the New World

The following content, reproduced from http://developers.sun.com.cn/blog/yutoujava/

Bytes -----------------------------------------------------------------------------------------------------

Java applications sometimes crash for various reasons. At this time, an error log similar to java_errorpid.log will be generated. You can get

How can I analyze the causes of crash? Next we will discuss in detail how to analyze the error logs of java_errorpid.log.

1. How to obtain this log file
If a serious error causes the Java Process to exit abnormally, we call it crash. At this time, a log file will be generated. By default

Files are generated in the working directory. However, you can use the following settings in the Java startup parameters to change the file location and naming rules. For example:
Java-XX: errorfile =/var/log/Java/java_error _ % P. Log
Put the error file under/var/log/Java and it will appear in the form of java_error_pid.log.

Ii. Causes of errors
There are multiple possible causes of serious errors. The bug of Java Virtual Machine itself is one of the reasons, but this may not be very large. In most cases,

It is caused by system library files, APIs, or third-party library files. The shortage of system resources may also cause such serious errors. When a crash occurs

Then, if you cannot locate the root cause, you should quickly find the work around und method.

3. Analysis of log files
First, check the log file header. For example, the following is the file header of the Error Log sent from a customer.

-------------------------------------
#
# An Unexpected error has been detected by hotspot virtual machine:
#
# Exception_access_violation (0xc0000005) at PC = 0x0815e87e, pid = 7268, tid = 4360
#
# Java VM: Java hotspot (TM) server VM (1.4.2 _ 13-b06 Mixed Mode)
# Problematic frame:
# V [JVM. dll + 0x15e87e]
#
--------------------------------------

There is a lot of useful information in the file header. "exception_access_violation" means that when Java uses crash,

The JVM code is running, rather than external Java code or other class library code. This is probably a JVM bug,

Not necessarily. In addition to "prediction_access_violation", there may be other information, such as "SIGSEGV (0xb )",

This means that the JVM is executing local or JNI code; "exception_stack_overflow" means this is a stack overflow error.

(*********** Here we know that I am running the JVM code when an error is reported, rather than external Java code or other class library code *********)

Another useful information is:
# Problematic frame:
# V [JVM. dll + 0x15e87e]

It indicates the library file from which the JVM is executing code During crash. In addition to "V", there may also be "C", "J", "V", and "J ". The specific meanings are as follows:

Frametype description:
C: native C Frame
J: interpreted Java Frame
V: vmframe
V: vmgenerated stub frame
J: Other frame types, including compiled Java Frames

(*********** Here we know that the error is V: vmframe *********)

After the file header, It is the dump information of the current thread, followed by the dump information of the JVM process, including the status, address, and Id of all threads. There is also the JVM status,

Heap status, dynamic connection library, and so on. The messy information contains useful information. Next we will analyze the java virtual

A typical example of crash.

4. crash caused by memory recovery
Crash caused by memory recovery has the following characteristics: in the log file header, there are generally "prediction_access _ violation" and

The "# problematic frame: # V [JVM. dll +..." information means that this is handled within the JVM and is mostly a JVM bug.

(*********** Here we know that when I report an error, it means that this is handled within JVM, and most of them are JVM bugs *********)

The fastest way to solve this type of problem is to bypass it.

In addition, at the end of the thread's dump information, we can also see the memory collection behavior, for example:

--------------- T h r e a d ---------------
Current thread (0x00a56668): vmthread [ID = 4360]
Siginfo: exceptioncode = 0xc0000005, reading address 0x00000057
Registers:
........

STACK: [0x03cf0000, 0x03d30000), SP = 0x03d2fc6, free space = 255 K
Native frames: (j = compiled Java code, j = interpreted, VV = VM code, c = native code)
V [JVM. dll + 0x15e87e]

Vm_operation (0x063efbac): full generation collection, mode: safepoint, requested by thread 0x040f83f8
------------------------------------------------------------

We can clearly see that the JVM is doing "full generation Collection ". You may also see other recycling behaviors:

Generation collection for allocation

Full generation collection

Parallel GC failed allocation

Parallel GC failed permanent allocation

Parallel GC system GC

***********)
For memory collection errors, we generally use methods that change the collection algorithm and parameters to bypass them. For example, besides the preceding

Log information. Some other information can be found in the heap information in the log:

--------------------------------------------------------------
Heap
Def New Generation total 22592 K, used 19530 K [0x10010000, 0x11890000, 0x138f0000)
Eden space 20096 K, 97% used [0x10010000, 0x11322bd8, 0x113b0000)
From space 2496 K, 0% used [0x113b0000, 0x113b0000, 0x11620000)
To space 2496 K, 0% used [0x11620000, 0x11620000, 0x11890000)
Tenured generation total 190696 K, used 100019 K [0x138f0000, 0x1f32a000, 0x30010000)
The space 190696 K, 52% used [0x138f0000, 0x19a9cf38, 0x19a9d000, 0x1f32a000)
Compacting perm Gen total 38656 K, used 38588 K [0x30010000, 0x325d0000, 0x34010000)
The space 38656 K, 99% used [0x30010000, 0x325bf038, 0x325bf200, 0x325d0000)
----------------------------------------------------------------

The above information shows that during crash, the JVM's permsize space is almost exhausted, and the recycling algorithm encountered an error when compressing the perm space.

Therefore, we recommend that you change the memory Reclaim Algorithm or increase the values of permsize and maxpermsize.

(******* You can try *******)

5. crash caused by Stack Overflow

Stack Overflow caused by Java code usually does not cause JVM crash, but throws a Java exception: Java. Lang. stackoverflowerror.

However, in the Java virtual machine, the Java code shares the same stack as the local C or C ++ code. In this way, stack overflow caused by local Code Execution,

It may cause the crash of JVM.

Stack Overflow causes crash to see the word "exception_stack_overflow" in the log file header. In addition

Information can also be found. For example:

Bytes -----------------------------------------------------------------------------------
# An Unexpected error has been detected by hotspot virtual machine:
#
# Prediction_stack_overflow (0xc00000fd) at PC = 0x10001011, pid = 296, tid = 2940
#
# Java VM: Java hotspot (TM) Client VM (1.6-Internal mixed mode, sharing)
# Problematic frame:
# C [App. dll + 0x1011]
#
--------------- T h r e a d ---------------
Current thread (0x0000000c0): javathread "Main" [_ thread_in_native, id = 2940]
:
STACK: [0x00040000,0x00080000), SP = 0x00041000, free space = 4 K
Native frames: (j = compiled Java code, j = interpreted, VV = VM code, c = native code)
C [App. dll + 0x1011]
C [App. dll + 0x1020]
C [App. dll + 0x1020]
:
C [App. dll + 0x1020]
C [App. dll + 0x1020]
... <More frames>...
Java frames: (j = compiled Java code, j = interpreted, VV = VM code)
J test. Foo () V + 0
J test. Main ([ljava/lang/string;) V + 0
V ~ Stubroutines: call_stub

--------------------------------------------------------------------------------

In the above information, we can find that this is a stack overflow error. The remaining space of the current stack is small (Free Space = 4 K ).

Therefore, we recommend that you increase the size of the JVM stack by two parameters: "-XSS" and "-XX: stackshadowpages = N ".

However, increasing the size of the stack also means that the maximum number of threads that can be opened is reduced in limited memory resources.

(****** There is still free space = 254 K remaining in the stack, obviously not consistent, so I decided to solve it again on vacation, O (Wait _ Wait) o... ******)

Conclusion:

I think that after C ++ creates a Java object, it has not been recycled. --------------- the authentication is complete.

I wonder if there are other suggestions in the garden. Welcome!

This problem was sent to two javaqq groups without any changes, so I decided to solve it myself. It seems that the more I am going to rely on myself.