JRE (version: 6.0 _ 18-b07) JVM automatically fails

01 #
02 # A fatal error has been detected by the Java Runtime Environment:
03 #
04 # SIGSEGV (0xb) at pc = 0x00002ad9817ab34e, pid = 10344, tid = 1083357504
05 #
06 # JRE version: 6.0 _ 18-b07
07 # Java VM: Java HotSpot (TM) 64-Bit Server VM (16.0-b13 mixed mode linux-amd64)
08 # Problematic frame:
09 # V [libjvm. so + 0x2de34e]
10 #
11 # If you wowould like to submit a bug report, please visit:
# Http://java.sun.com/webapps/bugreport/crash.jsp
13 #
In this section, there are three parts that need attention. One is that SIGSEGV is a signal name, indicating that this is an illegal error of creating a CORE file segment; the other is that it specifies the runtime environment, the jre version and jvm version. The third is the most important information, indicating the error. Here, V indicates a frame type, and here it refers to vmframe, in brackets, the error occurs in libjvm. in the so file, the offset of the specific position is the data after the plus sign. This is caused by jvm running errors.
The second part of this file is the thread currently being processed, or the thread that is running when the jvm crash is running. The details are as follows:
01 --------------- t h r e a d ---------------
02
03 Current thread (0x000000005d835000): GCTaskThread [stack: 0x0000000000004082b000, 0x000000004092c000] [id = 10346]
04
05 siginfo: si_signo = SIGSEGV: si_errno = 0, si_code = 128 (), si_addr = 0x0000000000000000
06
07 Registers:
08 RAX = 0x0000000000000001, RBX = 0x00002aaab9f2bdd0, RCX = 0x00002aaea56eb8, RDX = 0x000a000d003e0024
09 RSP = 0x000000004092aed0, RBP = 0x0000000000004092aef0, RSI = 0x00002aaab9f2bdd0, RDI = 0x000000005d883780
10 R8 = 0x00002aaea56d80, R9 = 0x0000000000000001, R10 = 0x00002ad981de7201, R11 = 0x00002ad981df46e0
11 R12 = 0x000000005d883780, R13 = 0x00002aaea56eb8, R14 = 0x00002aaaaea56eb8, R15 = 0x000000005d883780
12 RIP = 0x00002ad9817ab34e, EFL = 0x0000000000010202, CSGSFS = 0x0000000000000033, ERR = 0x0000000000000000
13 TRAPNO = 0x000000000000000d
14
15 Top of Stack: (sp = 0x000000004092aed0)
16 0x000000004092aed0: 2017100004092af00 20172ad9817ab3be
17 0x000000004092aee0: 20172aaab9f2bdd0 20172aaab9f2bdd0
 
The first line indicates that the program is running the garbage collection thread during the crash process. Therefore, it is suspected that the garbage collection is faulty, then this file guides us to the third part, the thread information dumped by dump.
01 --------------- p r o c e s ---------------
02 Java Threads: (=> current thread)
03 0x0000000056523000 JavaThread "Keep-Alive-Timer" daemon [_ thread_blocked, id = 12281,
04 stack (0x00000000478cc000, 0x00000000479cd000)]
05 0x0000000056a2e000 JavaThread "pool-7-thread-3" [_ thread_blocked, id = 8876, stack
06 (0x0000000046fc3000, 0x00000000470c4000)]
07 0x000000005687f800 JavaThread "ClientConnectionHandler" daemon [_ thread_in_native,
08 id = 4786, stack (0x0000000044599000, 0x000000004469a000)]
09 0x0000000056d0b000 JavaThread "MERGE2.FindSubgroups thread (channel = *******)"
10 daemon [_ thread_blocked, id = 4710, stack (0x00000000472c6000, 0x00000000473c7000)]
11 0x0000000056796800 JavaThread "pool-7-thread-2" [_ thread_blocked, id = 6325, stack
12 (0x00000000477cb000, 0x00000000478cc000)]
13
14 ...... N rows are omitted below
15 Heap
16 PSYoungGen total 160448 K, used 154320 K [0x00002aaac8b60000, 0x00002aaad2fc0000,
17 0x00002aaad3600000)
18 eden space 152448 K, 100% used [0x00002aaac8b60000, 0x00002aaad2040000, 0x00002aaad2040000)
19 from space 8000 K, 23% used [0x00002aaad27f0000, 0x00002aaad29c4018, 0x00002aaad2fc0000)
20 to space 7872 K, 12% used [0x00002aaad2040000, 0x00002aaad00004018, 0x00002aaad27f0000)
21 PSOldGen total 349568 K, used 344605 K [0x00002aaab3600000, 0x00002aaac8b60000,
22 0x00002aaac8b60000)
23 object space 349568 K, 98% used [0x00002aaab3600000, 0x00002aaac8687690, 0x00002aaac8b60000)
24 PSPermGen total 65792 K, used 48038 K [0x00002aaaae200000, 0x00002aaab2240000,
25 0x00002aaab3600000)
26 object space 65792 K, 73% used [0x00002aaaae200000, 0x00002aaab10e9bf8, 0x00002aaab2240000)
27
28 ...... N rows are omitted below
29 VM Arguments:
30 jvm_args:-Xms128m-Xmx512m-XX: PermSize = 64 m -Djava.net. preferIPv4Stack = true-Drialto. command. port = 6789-Drialto. work. dir =/home/admin/output/work
31 java_command: com. *******. *******. ******. apptask. CheckTaskStart
32 Launcher Type: SUN_STANDARD
33 Environment Variables:
34 JAVA_HOME =/usr/*****/java
35 PATH =/usr/*****/java/bin:/usr/******/ant/bin: /usr/*****/antx-2/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin: /usr/X11R6/bin:/home/admin/bin
36 LD_LIBRARY_PATH =/usr/*******/install/jdk1.6.0 _ 18/jre/lib/amd64/server: /usr/******/install/jdk1.6.0 _ 18/jre/lib/amd64: /usr/******/install/jdk1.6.0 _ 18/jre /.. /lib/amd64
37 SHELL =/bin/bash
After skipping the line message in the bolcked state of the N rows above, we finally see the heap information at this time. We found that the crash was in the eden zone when it reached 100% for young gc, so we have reason to believe it was caused by a problem with young gc. But what's the problem? So google searched for "jvm crash young gc ". Good luck! In the first article, we found the corresponding solution. It turned out to be a bug in JDK. The official documentation is as follows:
1 Card-Marking Optimization Issue
2 A flaw in the implementation of a card-marking performance optimization in the JVM can cause heap resume uption under some circumstances. this issue affects the CMS garbage collector prior to 65y, and the CMS, G1 and Parallel Garbage Collectors in 65y. the serial garbage collector is not affected. applications most likely to be affected by this issue are those that allocate very large objects which wocould not normally fit in Eden, or those that make extensive use of JNI Critical Sections (JNI Get/Release * Critical ).
3 This issue will be fixed in the next Java SE 6 update.
4 Meanwhile, as a workaround to the issue, users shocould disable this performance optimization by-XX:-performanceinitialcardmarks.
This section mainly involves three meanings: one is that the GC types affected by this bug are CMS class GC before 1.6180, serial GC is not affected; second, it refers to programs that will be affected, mainly those that will allocate a large number of objects and the eden area is too small or sensitive to JNI; third, the handling method is specified.
Are the preceding two conditions met? Through JVM parameters, we found that the GC type in this example is not specified, that is, the default parameter is used. What is the default GC type? Before JDK5.0, GC was a serial GC by default, but later, especially after JDK6.0, it became more intelligent. It was determined based on the machine's performance. How can this problem be solved? There are three original rules:
1. If you are using a server-type JVM, parallel GC will replace the serial GC;
2. When the program runs, it first checks the hardware environment. If it determines that its performance meets the standards of server-class machines, it will run the server-class JVM
3. What kind of machine meets the server standards? The CPU must be at least 2 cores and more than 2 GB of physical memory.
With the above three items, you can confirm that the task machine meets the server-class machine standards, so parallel GC is used, within the scope of the impact of this bug. For the second point, the JVM parameter only specifies MB of memory, except for 64 MB in the permanent zone. The default allocation ratio between the new generation and the old generation is, so the new generation is about 50 MB, it is indeed not a big number. It may have been because the task and web run on a machine, so the JVM heap parameters were set so small.
The subsequent solution is to standardize the JVM parameters of the task, and use-XX:-performanceinitialcardmarks to solve this bug!

Author: ERDP Technical Architecture"