Shulou(Shulou.com)06/03 Report--

This article will explain in detail the reasons for the collapse of JVM and how to solve it. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

A few days ago, when I was doing JNI, I reported a mistake about the collapse of JVM. 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 would like to submit a bug report, please visit:# http://java.sun.com/webapps/bugreport/crash.jsp#

I just want to generate a Date object for Java through C++ and output the current time. What we can probably know from this error message is JVM crash, which outputs errors to the hs_err_pid4752.log log. As a result, the error was reported dead or alive, and a log error log was generated. In fact, the operation produces one at a time, and the mistakes are all the same. I'll only mention one of them:

In order to prevent the leakage of local information, I screen out the path.

# # 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 0x00000000Registers:EAX=0x00000000, EBX=0x06f8c0f8, ECX=0x0006f954, EDX=0x00823df0ESP=0x0006f934, EBP=0x0006f980, ESI=0x0006f954, EDI=0x0006f9e8EIP=0x009fcf52, EFLAGS=0x00010246Top of Stack: (sp=0x0006f934) 0x0006f934: 009eb893 00000000 00823d30 009ecac30x0006f944: 00823d30 00000000 0006f9fc 0006f9980x0006f954: 00823df0 0082b438 009a1e20 00823d300x0006f964: 0006f980 009ebb6a 00823d30 0000000e0x0006f974: 00000004 0006f9e8 0006f998 0006f9e80x0006f984: 1000148b 00823df0 0082b434 000000000x0006f994: 0006f9fc 0006fa5c 06f8c0f8 06f8c0f80x0006f9a4: cccccccc cccccccc cccccccc ccccccccInstructions: (pc=0x009fcf52) 0x009fcf42: 44 24 04 24 fc 8b 00 8b 00 c3 8b 44 24 04 24 fc0x009fcf52: 8b 00 ff 74 24 04 8b c8 E8 93 fe ff ff c3 8b 44Stack: [0x000300000), sp=0x0006f934, free space=254kNative 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 () Vroom0j com.sy.test.TestNative.main ([Ljava/lang/String] ) StubRoutines::call_stubV 22v [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 () Vroom0j com.sy.test.TestNative.main ([Ljava/lang/String] ) current thread 22v ~ StubRoutines::call_stub- P R O C E S 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: NoneHeapdef new generation total 576K, used 209K [0x02de0000, 0x02e80000, 0x032c0000) eden space 512K, 40% used [0x02de0000, 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, 0x03420000) 0x06de0000 1408K, 0% 0x06de0000 [0x06de0000 0x032c0000, 0x032c0200, 0x03420000) compacting perm gen total 8192 K, used 1715K [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.dll0x7c800000-0x7c91d000 C:\ WINDOWS\ system32\ kernel32.dll0x77da0000-0x77e49000 C:\ WINDOWS\ system32\ ADVAPI32.dll0x77e50000-0x77ee2000 C:\ WINDOWS\ system32\ RPCRT4.dll0x77fc0000-0x77fd1000 C:\ WINDOWS\ system32\ Secur32.dll0x77d10000-0x77d9f000 C:\ WINDOWS\ system32\ USER32.dll0x77ef0000-0x77f38000 C :\ WINDOWS\ system32\ GDI32.dll0x77be0000-0x77c38000 C:\ WINDOWS\ system32\ MSVCRT.dll0x76300000-0x7631d000 C:\ WINDOWS\ system32\ IMM32.DLL0x62c20000-0x62c29000 C:\ WINDOWS\ system32\ LPK.DLL0x73fa0000-0x7400b000 C:\ WINDOWS\ system32\ USP10.dll0x6d710000-0x6d723000 C:\ PROGRA~1\ KASPER~1\ KASPER~1\ mzvkbd.dll0x76bc0000-0x76bcb000 C:\ WINDOWS\ system32\ PSAPI.DLL0x6d730000-0x6d743000 C:\ PROGRA~1\ KASPER~1\ KASPER~1\ mzvkbd3.dll0x6d020000-0x6d035000 C:\ PROGRA~1\ KASPER~1\ KASPER~1 C:\ adialhk.dll0x77f40000\ KASPER~1 SHLWAPI.dll0x6d4c0000-0x6d4c6000 C:\ PROGRA~1\ KASPER~1\ KASPER~1\ kloehk.dll0x00960000-0x00afe000 * * 0x76b10000-0x76b3a000 C:\ WINDOWS\ system32\ WINMM.dll0x6d290000-0x6d298000 * * 0x6d610000-0x6d61c000 * * 0x6d310000-0x6d32d000 * * 0x6d630000-0x6d63f000 * * 0x10000000-0x1004e000 * * VM Arguments:java_command: com .sy.test.TestNativeLauncher Type: SUN_STANDARDEnvironment Variables:JAVA_HOME=**CLASSPATH=**PATH=**USERNAME=userOS=Windows_NTPROCESSOR_IDENTIFIER=x86 Family 6 Model 14 Stepping 8 GenuineIntel- S Y S T E M-OS: Windows XP Build 2600 Service Pack 2CPU:total 1 (cores per cpu 1, threads per core 1) family 6 model 14 stepping 8, cmov, cx8, fxsr, mmx, sse, sse2Memory: 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

Looking at the error logs, we can conclude that it is because I made a mistake when I called the local dll file with the main function of Java.

My preliminary inference is that my C++ generated a Java object that was passed to the Java class and was not recycled. Causing a memory leak.

But because I am a beginner, so I am not familiar with C++ control Java, so after debugging, C++ compiler can not pass. As the recent exam pressure is too great, I am forced to put aside this question for the time being.

But he didn't solve the problem, so he began to search for "long information retrieval" to discover the new world.

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

-

Java applications sometimes Crash for a variety of reasons, which results in an error log similar to java_errorpid.log. You can get this log, how to analyze the reasons for Crash? Let's discuss in detail how to analyze java_errorpid.log 's error log.

one。 How to get this log file

If a serious error causes the Java process to exit abnormally, we call it Crash, and a log file is generated. By default, this file is generated in the working directory. However, you can change the location and naming convention of the file by setting the following settings in the Java startup parameters. For example:

Java-XX:ErrorFile=/var/log/java/java_error_%p.log

Put the error file under / var/log/java and appear in the form of java_error_pid.log.

two。 The cause of the error

There are many possible causes of serious errors. The Bug of the Java virtual machine itself is one of the reasons, but this is not very likely. In the vast majority of cases, it is caused by the system's library files, API, or third-party library files; a shortage of system resources can also cause such serious errors. After the occurrence of Crash, if you cannot locate the root cause, you should also quickly find the method of Work Around.

three。 Analysis of log files

First check the header of the log: for example, the following is the 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 applies Crash, it is running JVM's own code, rather than external Java code or other class library code. This is probably JVM's Bug, but

Not necessarily. In addition to "EXCEPTION_ACCESS_VIOLATION", there could be other information, such as "SIGSEGV (0xb)", which means that JVM is executing local or JNI code; "EXCEPTION_STACK_OVERFLOW" means that this is a stack overflow error.

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

Another useful piece of information is:

# Problematic frame:# V [jvm.dll+0x15e87e]

It indicates which library file JVM is executing code from when Crash. In addition to "V", it may also be "C", "j", "v", "J". The specific meaning is as follows:

FrameType Description:C: Native C framej: Interpreted Java frameV: VMframev: VMgenerated stub frameJ: Other frame types, including compiled Java frames

(* looking at this, we know that when I made a mistake, it was V: VMframe *)

After the file header is the DUMP information of the current thread, and after the thread is the DUMP information of the JVM process, including the status, address, and ID of all threads. Finally, there is information about JVM status, Heap status, dynamic link libraries, etc. These disturbing messages contain very useful information. Let's analyze a typical example of Java virtual machine Crash based on several concrete examples.

four。 Crash caused by memory recovery

Crash caused by memory recovery has the following characteristics: there are generally "EXCEPTION_ACCESS _ VIOLATION" and "# Problematic frame: # V [jvm.dll+...." in the log file header. , which means that this is handled internally in JVM and is mostly JVM's Bug.

(* when we see here, we know that when I report an error, it means that it is handled within JVM, and it is mostly JVM's Bug*.)

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

In addition, at the end of the DUMP information for Thread, you can also see the behavior related to memory recycling, such as:

-T H R E A D-Current thread (0x00a56668): VMThread [id=4360] siginfo: ExceptionCode=0xc0000005, reading address 0x00000057Registers:.Stack: [0x03cf0000author0x03d30000), sp=0x03d2fc18, free space=255kNative 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 0x040f83f8Murray-

You can clearly see that JVM is doing "full generation collection". It is also possible to see other recycling behaviors:

Generation collection for allocationfull generation collectionparallel gc failed allocationparallel gc failed permanent allocationparallel gc system gc

(* I didn't encounter any of these mistakes *)

The error of memory recovery is generally bypassed by changing the algorithm and parameters of memory recovery. For example, in addition to the log information above, the log from the customer can also find some other information in the log Heap information:

-Heapdef 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, 0x19a9d000, 0x1f32a000) compacting perm gen total 38656K, used 38588K [0x30010000, 0x325d0000, 0x34010000) the space 38656K, 99% used [0x30010000, 0x325bf038, 0x325bf200, 0x325d0000)-

The above information shows that at the time of Crash, JVM's PermSize space has almost been consumed, and the recycling algorithm has made a mistake in compressing Perm space.

Therefore, it is recommended to change the algorithm of memory collection or expand the values of PermSize and MaxPermSize.

(* this can be tried *)

five。 Crash caused by stack overflow

Stack overflows caused by Java code usually do not cause JVM's Crash, but throw a Java exception: java.lang.StackOverflowError.

But in the Java virtual machine, the Java code and the local C or C++ code share the same Stack. In this way, the stack overflow caused by the execution of native code

It is possible to cause JVM's Crash.

Crash caused by stack overflow will see the word "EXCEPTION_STACK_OVERFLOW" in the header of the log. In addition, the Stack of the current thread

Some information can also be found in the information. For example, the following example:

-# An unexpected error has been detected by HotSpot Virtual Machine:## EXCEPTION_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 (0x000367c0): JavaThread "main" [_ thread_in_native, id=2940]: Stack: [0x00040000author0x00080000), sp=0x00041000, free space=4kNative 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]. Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j Test.foo () VB0j Test.main ([Ljava/lang/String;) VIP0v ~ StubRoutines::call_stub

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

Therefore, it is recommended to increase the size of the Stack of JVM, mainly to design 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 will be reduced in limited memory resources.

I think there is still no recycling after C++ establishes the Java object.

About the reasons for the collapse of JVM and how to solve the sharing here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.