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

This article introduces the reasons for the collapse of JVM and what the solution is. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

The JVM crash 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 that

JVM crash, output errors to 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 EA 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 00000000000 0x0006f994: 0006f9fc 0006fa5c 06f8c0f8 06f8c0f8 0x0006f9a4: cccccccc cccccccc cccccccc 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 93 fe ff ff c3 8b 44 Stack: [0x00030000 0x00070000), sp=0x0006f934 Free space=254k 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 () Vasi0j com.sy.test.TestNative.main ([Ljava/lang/String] ) Vbelt 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 () Vang 0j 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: None Heap def 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, 0x06de0000) the space 1408K, 0% used [0x032c0000, 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.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\ PROGRA~1\ PROGRA~1. 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: 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. Due to the pressure of recent exams

It is so big that I am forced to put aside the problem for the time being.

Java applications sometimes Crash for a variety of reasons, which results in an error log similar to java_errorpid.log. You can get it.

How to analyze the cause of Crash in this log? 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

The file will be 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 situation is likely to be 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 JVM crash message 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 frame j: Interpreted Java frame V: VMframe v: VMgenerated stub frame J: Other frame types, including compiled Java frames (* looking here 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 JVM status.

Information about Heap status, dynamic link libraries, etc. These disturbing messages contain very useful information. Let's analyze a typical example of a JVM crash based on a few concrete examples.

four。 Crash caused by memory recovery

The Crash caused by memory recovery has the following characteristics: there are generally "EXCEPTION_ACCESS _ VIOLATION" and "log _ VIOLATION" in the log file header.

"# Problematic frame: # V [jvm.dll+...." , 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 0x00000057 Registers: Stack: [0x03cf0000d0x03d30000), 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

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

For memory recovery errors, general

Generation collection for allocation full generation collection parallel gc failed allocation parallel gc failed permanent allocation parallel gc system gc (* I didn't encounter any of these mistakes *)

Bypass it by changing the recycling algorithm and parameters. 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:

-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, 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 may cause the Crash of JVM. Crash caused by stack overflow will see the word "EXCEPTION_STACK_OVERFLOW" in the header of the log. In addition, some information can be found in the Stack information of the current thread. 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: [0x00040000fu0x00080000), sp=0x00041000, free space=4k 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]. 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. (* there is still free space=254k left in my stack, which obviously doesn't match, so I decided to deal with it during the holiday, o (∩ _ ∩) o. *)

The cause and solution of JVM collapse conclusion:

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

On the causes of the collapse of JVM and what is the solution to share 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.