JDK-8139366 : java -XX:+UseG1GC -Xmx2m -version SEGV in RemoveSelfForwardPtrObjClosure::do_object
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9-repo-jigsaw
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2015-10-10
  • Updated: 2016-04-21
  • Resolved: 2016-04-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Duplicate :  
JDK-8152949 - Jigsaw crash when Klass in _fixup_module_field_list is unloaded
Description
This issue reproduces with a build of the jigsaw/jake forest, this forest is JDK 9 + the module system being defined by JSR 376 + JEP 261.

With the module system there is code executed at startup to resolve the initial module and define the resulting module graph to the runtime. With a run-time image containing all modules it currently adds ~800k of heap usage. This is enough to trigger OOME with G1 when running with the minimum allowed heap (2MB) and I assume 1MB regions. Sometimes OOME is thrown, sometimes it SEGVs.

To duplicate the issue requires building http://hg.openjdk.java.net/jigsaw/jake/ (it builds just like any jdk9/* forest). Then try:

   java -XX:+UseG1GC -Xmx2m -version

Sometimes it will fail correctly with an OOME, sometimes it will SEGV but not always in the same place. RemoveSelfForwardPtrObjClosure::do_object seems to be the most popular:

Stack: [0x00007f648471d000,0x00007f648481e000],  sp=0x00007f648481cca0,  free space=1023k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x608113]  RemoveSelfForwardPtrObjClosure::do_object(oopDesc*)+0x73
V  [libjvm.so+0x684b76]  G1OffsetTableContigSpace::object_iterate(ObjectClosure*)+0x66
V  [libjvm.so+0x607f06]  RemoveSelfForwardPtrHRClosure::doHeapRegion(HeapRegion*)+0x106
V  [libjvm.so+0x5efd02]  G1CollectedHeap::collection_set_iterate_from(HeapRegion*, HeapRegionClosure*)+0x32
V  [libjvm.so+0x607c50]  G1ParRemoveSelfForwardPtrsTask::work(unsigned int)+0xc0
V  [libjvm.so+0xaf088b]  GangWorker::loop()+0x2b
V  [libjvm.so+0x923fd2]  java_start(Thread*)+0xc2
Comments
Moving this over to Runtime.
15-04-2016
It looks like this could be caused by the bug in JDK-8152949.
12-04-2016
Lois has agreed to look at this to see if it still duplicates and to see if this is specific to jake or not.
18-02-2016
Is anyone able to duplicate this now? We have reduced the footprint overhead during startup so that we can start with -Xmx2m now. It may be that we avoiding this SEGV or maybe the SEGV is something that has been addressed by another issue.
12-02-2016
JDK-8076621 will deal with the OOME issue due to more heap usage in Jake, the crash still needs to be fixed though.
01-02-2016
I removed g1 gc label since this asserts the same way with parallel gc.
13-10-2015
Also asserts with +UseParallelGC: $ ./build/linux-x86_64-normal-server-slowdebug/images/jdk/bin/java -Xmx2m -XX:+PrintFlagsFinal -XX:+PrintGCDetails -XX:+PrintHeapAtGC -XX:+PrintHeapAtGCExtended -XX:+VerifyBeforeGC -XX:+VerifyAfterGC -XX:+UseCompressedOops -XX:+TraceModules -XX:+UseParallelGC -version # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/oop.inline.hpp:192 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/eric/views/jake/hotspot/src/share/vm/oops/oop.inline.hpp:192), pid=11166, tid=11167 # assert(check_obj_alignment(result)) failed: address not aligned: 0x0000000000000031 # # JRE version: OpenJDK Runtime Environment (9.0) (build 1.9.0-internal-debug-eric_2015_10_12_11_20-b00) # Java VM: OpenJDK 64-Bit Server VM (1.9.0-internal-debug-eric_2015_10_12_11_20-b00, mixed mode, tiered, compressed oops, parallel gc, linux-amd64) # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /home/eric/views/jake/core.11166) # # An error report file with more information is saved as: # /home/eric/views/jake/hs_err_pid11166.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp #
13-10-2015
Just stating the obvious, with -XX:-UseCompressedOops the memory usage is probably even higher than without, so the code may go another path immediately.
13-10-2015
Indeed, I cannot get it to crash or misbehave if I use -UseCompressedOops.
12-10-2015
Running the release build from today I get several different versions of problems happening here: I noticed that with -UseCompressedOops it "always" throws the OOM correctly from various locations (I tried it ~15 times) =============================== #7: [GC concurrent-mark-start] #8: [Full GC (Allocation Failure) 1499K->807K(2048K), 0.0095206 secs] [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 1499.0K(2048.0K)->807.4K(2048.0K)], [Metaspace: 3915K->3915K(1056768K)] [Times: user=0.02 sys=0.00 real=0.02 secs] #7: [GC concurrent-mark-abort] Error occurred during initialization of VM java.lang.ClassCastException: java.lang.reflect.Module (in module: java.base) cannot be cast to java.lang.String (in module: java.base) at java.lang.module.Resolver.checkExportSuppliers(java.base@9.0/Resolver.java:806) at java.lang.module.Resolver.resolve(java.base@9.0/Resolver.java:220) at java.lang.module.Resolver.resolve(java.base@9.0/Resolver.java:173) at java.lang.module.Configuration.resolve(java.base@9.0/Configuration.java:229) at jdk.internal.module.ModuleBootstrap.boot(java.base@9.0/ModuleBootstrap.java:170) at java.lang.System.initPhase2(java.base@9.0/System.java:1261) ========================= #7: [GC concurrent-mark-start] #8: [Full GC (Allocation Failure) 1495K->803K(2048K), 0.0099894 secs] [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 1495.5K(2048.0K)->803.3K(2048.0K)], [Metaspace: 3914K->3914K(1056768K)] [Times: user=0.02 sys=0.00 real=0.01 secs] #7: [GC concurrent-mark-abort] # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f03663f7f22, pid=28234, tid=28235 # # JRE version: OpenJDK Runtime Environment (9.0) (build 1.9.0-internal-eric_2015_10_12_13_12-b00) # Java VM: OpenJDK 64-Bit Server VM (1.9.0-internal-eric_2015_10_12_13_12-b00, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # j java.lang.module.Resolver.checkExportSuppliers(Ljava/util/Map;)V+73 java.base@9.0 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /home/eric/views/jake/core.28234) # # An error report file with more information is saved as: # /home/eric/views/jake/hs_err_pid28234.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # Aborted (core dumped) ============================= #7: [GC concurrent-mark-start] #8: [Full GC (Allocation Failure) 1499K->806K(2048K), 0.0087347 secs] [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 1499.0K(2048.0K)->807.0K(2048.0K)], [Metaspace: 3917K->3917K(1056768K)] [Times: user=0.01 sys=0.00 real=0.00 secs] #7: [GC concurrent-mark-abort] #9: [GC pause (G1 Evacuation Pause) (young)# # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f5b2a2fcde3, pid=28308, tid=28325 # # JRE version: OpenJDK Runtime Environment (9.0) (build 1.9.0-internal-eric_2015_10_12_13_12-b00) # Java VM: OpenJDK 64-Bit Server VM (1.9.0-internal-eric_2015_10_12_13_12-b00, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x607de3] G1ParScanThreadState::copy_to_survivor_space(InCSetState, oopDesc*, markOopDesc*)+0x293 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %P" (or dumping to /home/eric/views/jake/core.28308) # # An error report file with more information is saved as: # /home/eric/views/jake/hs_err_pid28308.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # ==================== #13: [Full GC (Allocation Failure) 1118K->1118K(2048K), 0.0051284 secs] [Eden: 0.0B(1024.0K)->0.0B(1024.0K) Survivors: 0.0B->0.0B Heap: 1118.1K(2048.0K)->1118.1K(2048.0K)], [Metaspace: 4157K->4157K(1056768K)] [Times: user=0.01 sys=0.00 real=0.00 secs] Error occurred during initialization of VM java.lang.OutOfMemoryError: Java heap space at java.util.HashMap.resize(java.base@9.0/HashMap.java:703) at java.util.HashMap.putVal(java.base@9.0/HashMap.java:662) at java.util.HashMap.put(java.base@9.0/HashMap.java:611) at java.lang.module.Resolver.checkExportSuppliers(java.base@9.0/Resolver.java:825) at java.lang.module.Resolver.resolve(java.base@9.0/Resolver.java:220) at java.lang.module.Resolver.resolve(java.base@9.0/Resolver.java:173) at java.lang.module.Configuration.resolve(java.base@9.0/Configuration.java:229) at jdk.internal.module.ModuleBootstrap.boot(java.base@9.0/ModuleBootstrap.java:170) at java.lang.System.initPhase2(java.base@9.0/System.java:1261) #11: [GC concurrent-mark-abort]
12-10-2015