All geek questions in one place

Jdk6 Problem frame: # J java.util.LinkedHashMap.addEntry (ILjava / lang / Object; Ljava / lang / Object; I) V

Is there any way to resolve this error report:

# A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fc955e66998, pid=25851, tid=140467030525696 # # JRE version: 6.0_37-b06 # Java VM: Java HotSpot(TM) 64-Bit Server VM (20.12-b01 mixed mode linux-amd64 compressed oops) # Problematic frame: # J java.util.LinkedHashMap.addEntry(ILjava/lang/Object;Ljava/lang/Object;I)V

?

Failure occurs quite often (1-2 times a day when creating a web server), almost always with different reports of problem frames.

The following are examples of error messages:

 # J java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.addConditionWaiter()Ljava/util/concurrent/locks/AbstractQueuedSynchronizer$Node; # J java.util.LinkedHashMap.addEntry(ILjava/lang/Object;Ljava/lang/Object;I)V # C [libc.so.6+0x6bb34] # C [libgobject-2.0.so.0+0x2346f] g_type_check_instance_is_a+0x43 # C [libgobject-2.0.so.0+0x2346f] g_type_check_instance_is_a+0x43 # V [libjvm.so+0x4d3360] # V [libjvm.so+0x32d166] CardTableRS::write_ref_field_gc_par(void*, oopDesc*)+0x26 # V [libjvm.so+0x7a33e2] ContiguousSpace::prepare_for_compaction(CompactPoint*)+0x242 # V [libjvm.so+0x4d3360] # V [libjvm.so+0x76943b] ReferenceProcessor::balance_queues(DiscoveredList*)+0x32b # V [libjvm.so+0x4d3360] # V [libjvm.so+0x32d166] CardTableRS::write_ref_field_gc_par(void*, oopDesc*)+0x26 # V [libjvm.so+0x4d3360] # V [libjvm.so+0x4d3360] # V [libjvm.so+0x76943b] ReferenceProcessor::balance_queues(DiscoveredList*)+0x32b

The only thing that seems to cause crashes is about 30 gigabytes of memory usage, although this was not always the case (when the gc log shows low memory usage), some crashes occur. Accidents do not occur when operating in -Xint mode, but this mode is so slow that it is not an option.

It seems difficult to make any simple “reproducible code” to reproduce the error that occurs in the production environment of a complex application.

What to do? I reported this on the Oracle website, but ...

I do not suspect a problem with the hardware memory because nothing else happens except java. And there is no jni user code in the application.

Our parameters vm -server -Xss4096k -Xms32255M -Xmx32255M -Xnoclassgc -XX:+UseNUMA -XX:MaxPermSize=512m -XX:+UseGCOverheadLimit -verbose:gc -Xmaxf1 -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:+AggressiveOpts -XX:+ScavengeBeforeFullGC -XX:CMSFullGCsBeforeCompaction=10 -XX:CMSInitiatingOccupancyFraction=70 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:+CMSParallelRemarkEnabled -XX:+ParallelRefProcEnabled -XX:GCTimeRatio=19 -XX:+UseAdaptiveSizePolicy -XX:MaxGCPauseMillis=500 -Xloggc:gc.log .

+4
source share
4 answers

Upgrading to the jdk7 Java (TM) SE Runtime Environment (version 1.7.0_09-b05) and there have been no problems since; follwing vmargs:

 -server -Xss4096k -XX:MaxPermSize=512m -Xms32255M -Xmx32255M -Xnoclassgc -XX:+UseNUMA -XX:+UseBiasedLocking -XX:+UseFastAccessorMethods -XX:ReservedCodeCacheSize=48m -XX:+UseStringCache -XX:+HeapDumpOnOutOfMemoryError -XX:+UseGCOverheadLimit -Duser.timezone=EET -Xmaxf1 -XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:+AggressiveOpts -XX:CMSInitiatingOccupancyFraction=70 -XX:+ParallelRefProcEnabled -XX:+UseAdaptiveSizePolicy -XX:MaxGCPauseMillis=100 -XX:+UseG1GC -XX:GCPauseIntervalMillis=3000 -XX:+PrintGCDetails -XX:+PrintHeapAtGC -Xloggc:gc.log
0
source

While it is possible that the crash is caused by a JVM error, it is most likely caused by some native JNI / JNA code that you wrote, or which is part of some third-party library that you are using.

What to do?

Here's a blog on how to get started with debugging a crash dump: http://www.javacodegeeks.com/2012/01/debugging-jvm.html

In your case, the fact that the reports are all different makes the search difficult. It looks like you might have a problem with something "randomly" destroying heap objects.

I reported this on the Oracle disaster site, though ...

Unless you have a support contract, Oracle is unlikely to come back with a solution.

0
source

If the failure happens with clearly random reasons, I would think about a possible hardware problem (for example, a deceptive RAM). I would be inclined to run a full battery of hardware diagnostics on the server and see that it all causes something.

0
source

I found this article on the Internet. If you use the AggressiveOpts option of the Java ™ Virtual Machine (JVM) with a Java Platform Enterprise Edition (Java EE) application that contains Enterprise JavaBeans (EJB) files, the JVM may crash. To work around this issue, disable DoEscapeAnalysis optimization using the following arguments:

-XX: + AggressiveOpts -XX: -DoEscapeAnalysis`:

http://www-01.ibm.com/support/docview.wss?uid=swg21422605

What is strange is that -XX:-CMSIncrementalMode made the system VERY unstable, I had to enable this option.

0
source

Source: https://habr.com/ru/post/1441092/

More articles:


All Articles