The cause and resolution of the JVM crash!

The cause and resolution of the JVM crash!

A few days ago, when I was doing jni, I reported a bad JVM crash. The error message is as follows:

# Unexpected error have been detected by HotSpot Vsan: # # Exception_access_violation (0xc0000005) at pc=0  X009fcf52, 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 are saved as Hs_err_pid4752.log # If you would like to S Ubmit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # I just want to generate a Java Date object from C + + and then Outputs the current time. With this error message, we can probably tell

The JVM crash, outputting errors to the Hs_err_pid4752.log log.

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

The result of the operation is reported this error, also produced a log error logs. Actually run one at a time, it's all the same, I'll just give one of them:

In order to prevent the information leakage, I put the path screen off.

# Unexpected error have been detected by HotSpot Vsan: # # Exception_access_violation (0xc0000005) at pc=0  X009fcf52, 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 0   006f998 0x0006f954:00823df0 0082b438 009a1e20 00823d30 0x0006f964:0006f980 009ebb6a 00823d30 0000000e 0x0006f974: 00000004 0006f9e8 0006f998 0006f9e8 0x0006f984:1000148b 00823df0 0082b434 00000000 0X0006F994:0006F9FC 0006fa5c 06f8 C0f8 06f8c0f8 0X0006F9A4:CCCCCCCC CCCCCCCC CCCCCCCC CCCCCCCC

Instructions: (pc=0x009fcf52) 0x009fcf42:44 74 FC 8b 8b XX C3 8b 24 0 FC 0x009fcf52:8b 4 8b C8 E8-FE FF FF C3 8b 44

Stack: [0x00030000,0x00070000], sp=0x0006f934, free space=254k Native frames: (j=compiled Java Code, j=interpreted, Vv=v M Code, c=native code) V [jvm.dll+0x9cf52] c [nativecode.dll+0x148b] C [nativecode.dll+0x1253] J Com.sy.test.TestNativ E.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 [JAVAW.EXE+0X14C5] c [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.Test Native.main ([ljava/lang/string;) v+22 V ~stubroutines::call_stub

---------------P R O C E s S---------------

Java Threads: (= = current thread) 0x008306d0 javathread "Low Memory Detector" daemon [_thread_blocked, id=5624] 0 X0082fb30 javathread "CompilerThread0" daemon [_thread_blocked, id=5988] 0x0082e8c0 javathread "Signal Dispatcher" Daemo n [_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 576K, used 209K [0x02de0000, 0x02e80000, 0x032c0000) Eden Space 512K, 40% used [0x02de 0000, 0x02e14510, 0x02e60000) from space 64K, 0% used [0x02e60000, 0x02e60000, 0x02e70000] to space 64K, 0% used [0x02e70000, 0x02e70000, 0x02e80000) tenured generation total 1408K, used 0K [0x032c0000, 0x03420000, 0x06de0000) t He space 1408K, 0% used [0x032c0000, 0x032c0000, 0x032c0200, 0x03420000) compacting Perm gen Total 8192K, used 1715K [ 0x06de0000, 0x075e0000, 0x0ade0000) The space 8192K, 20% used [0x06de0000, 0x06f8cdb0, 0x06f8ce00, 0x075e0000) No Shar Ed 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 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 stepping 8, Cmov, cx8, FXSR, MMX, SSE, SSE2

memory:4k page, physical 1300464k (465904k free), swap 3092560k (2157304k free)

Vm_info:java HotSpot (TM) Client VM (1.5.0_14-B03) for windows-x86, built on Oct 5-01:21:52 by ' java_re ' with MS vc+ + 6.0

You can tell by the error log that I was wrong when I called the local DLL file using Java's main function.

I initially inferred that my C + + generated Java objects that were passed to Java classes without recycling. Cause a memory leak.

But because I am a beginner, so the C + + control Java is not familiar, so after debugging, C + + compiler pass. Due to the recent test pressure

It was so big that I was forced to put aside the problem for the first moment.

But do not solve the heart uncomfortable, so began the search "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "" "

Discover new Land "" "" "" "" "

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

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

Java applications can sometimes be crash for a variety of reasons, creating a java_errorpid.log-like error log. We can get it.

This log, how to analyze the cause of crash? Let's discuss in detail how to parse the Java_errorpid.log error log.

I. How to get this log file if there is a serious error causing the Java process to exit abnormally, we call crash, which will generate a log file. By default, this

The file will be generated in the working directory. However, you can change the location and naming rules for this file by using the following settings in the Java startup parameters. For example: Java-xx:errorfile=/var/log/java/java_error_%p.log the error file under/var/log/java and appears in Java_error_pid.log form.

Two. There are various possibilities for causes of serious errors due to the cause of the error. A bug in the Java Virtual machine itself is one of the reasons, but this may not be great. In the vast majority of cases,

is due to the system's library files, APIs, or third-party library files, and the shortage of system resources can also cause this serious error. In the event of crash

Then, if you can't locate the root cause, you should quickly find a way to work around.

Three. Analysis of log files first check the log header: for example, the following is the header of the error log sent from a client

-------------------------------------# Unexpected error have 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 m ixed 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 application crash,

Running the JVM's own code, not external Java code or other class library code. This situation is most likely a bug in the JVM, but

And not necessarily. In addition to "exception_access_violation", there may be other information, such as "SIGSEGV (0XB)",

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

(********** see here we know that I was running the JVM's own code when I got an error, not the external Java code or other class library code *********)

Another useful message is: # problematic frame: # V [jvm.dll+0x15e87e]

It shows crash the JVM is executing code from which library file. In addition to "V", there may be "C", "J", "V", "J". The specific meaning of the expression is as follows:

Frametype description:c: Native C frame j:interpreted Java frame v:vmframe v:vmgenerated stub frame j:other frame Typ ES, including compiled Java frames

(********** see here we know when I error is v:vmframe this situation *********)

After the file header is the dump information for the current thread, the thread is then the dump information for the JVM process, including the status, address, and ID of all threads. Finally there is the JVM State,

Heap status, dynamic Connection library, and so on. These disturbing messages contain very useful information. Let's analyze the Java virtual with a few specific examples

Typical examples of machine crash.

Four. Crash memory recovery caused by memory recovery crash has the following characteristics: In the log file header generally have "exception_access _violation" and

The "# Problematic frame: # V [jvm.dll+ ...] message means that this is handled internally within the JVM and is mostly a JVM bug.

(********** see here we know that my error means that this is handled internally within the JVM, and mostly the JVM's bug*********)

The quickest way to get around this kind of problem is to bypass it.

In addition, at the end of the dump information for thread, you can see the behavior of memory recycling, for example:

---------------T H R E A D---------------Current thread (0x00a56668): Vmthread [id=4360] siginfo:exceptioncode=0xc0000 005, reading address 0x00000057 registers: ...

Stack: [0x03cf0000,0x03d30000], sp=0x03d2fc18, free space=255k 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------------------ ------------------------------------------

It is clear to see that the JVM is doing "full generation collection". It is also possible to see other recycling behaviors:

Generation collection for allocation

Full Generation Collection

Parallel GC failed allocation

Parallel GC failed permanent allocation

Parallel GC System GC

(*********** These mistakes, I did not touch the ***********) for memory recovery errors, generally take the method of changing the recovery algorithm and parameters to go around the past. For example, the logs from the customer except for the above

Log information, some additional information can be found in the heap information in the log:

--------------------------------------------------------------Heap def New Generation total 22592K, used 19530K [ 0x10010000, 0x11890000, 0x138f0000) Eden Space 20096K, 97% used [0x10010000, 0x11322bd8, 0x113b0000) from Space 2496K, 0% Used [0x113b0000, 0x113b0000, 0x11620000) to space 2496K, 0% used [0x11620000, 0x11620000, 0x11890000] tenured generation Total 190696K, used 100019K [0x138f0000, 0x1f32a000, 0x30010000) The space 190696K, 52% used [0x138f0000, 0x19a9cf38, 0x19 a9d000, 0x1f32a000) compacting Perm gen Total 38656K, used 38588K [0x30010000, 0x325d0000, 0x34010000) The space 38656K, 9 9% used [0x30010000, 0x325bf038, 0x325bf200, 0x325d0000)----------------------------------------------------------- -----

The above information can be seen in the crash, the JVM's permsize space is almost exhausted, and the recovery algorithm in the compressed perm space when the error.

Therefore, it is recommended to change the memory recovery algorithm, or enlarge the permsize and MaxPermSize values.

(******* this can try *******)

Five. Crash caused by Stack overflow

The stack overflow caused by Java code usually does not cause the JVM to crash, but instead throws a Java exception: Java.lang.StackOverflowError.

In a Java virtual machine, however, Java's Code is common to the same stack as the local C or C + + code. Thus, the stack overflow caused by the execution of local code,

It is possible to cause the JVM to crash.

Crash caused by stack overflow will see the word "exception_stack_overflow" in the log file header. In addition, the stack on the current thread

Information can also be found in the message. For example, the following example:

-----------------------------------------------------------------------------------# An unexpected error have been Detected by HotSpot Vsan: # # Exception_stack_overflow (0XC00000FD) at pc=0x10001011, pid=296, tid=2940 # # Jav A 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 (0x000367c0): Javathread "Main" [_thread_in_native, id=2940]: Stack: [0x 00040000,0x00080000), sp=0x00041000, free space=4k Native frames: (j=compiled Java Code, j=interpreted, VV=VM code, C=nati ve code) c [app.dll+0x1011] c [app.dll+0x1020] c [app.dll+0x1020]: c [app.dll+0x1020] c [app.dll+0x1020] ... <more fram Es>, ..... 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 ~stub Routines::call_stub

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

In the above information, you can see that this is a stack overflow error. And the remaining space on the current stack is already very small (free space =4k).

It is therefore recommended that the JVM stack be sized up to design two main parameters: "-XSS" and "-xx:stackshadowpages=n".

However, resizing the stack also means that the maximum number of threads that can be opened in a limited memory resource is reduced.

(****** my stack remaining free space=254k, obviously not, so I decided to solve the holiday, O (∩_∩) o...******)

Conclusion:

I think it's still a C + + build Java object, no recycling-----------------authentication complete

I wonder if anyone in the garden can have any other suggestions. Welcome to the present!

This problem sent to two JAVAQQ group have no movement, so decided to solve their own, it seems that the more backward to rely on their own.

The cause and resolution of the JVM crash!