JDK-8253665 : assert(!_g1h->is_humongous(desired_word_size)) failed: we should not be seeing humongous-size allocations in this path
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2020-09-25
  • Updated: 2020-10-19
  • Resolved: 2020-10-19
Related Reports
Duplicate :  
JDK-8253261 - Disable CDS full module graph until JDK-8253081 is fixed
Description
 # To suppress the following error report, specify this argument
[2020-09-24T18:37:08,632Z] # after -XX: or in .hotspotrc:  SuppressErrorAt=/g1Allocator.cpp:266
[2020-09-24T18:37:08,632Z] #
[2020-09-24T18:37:08,632Z] # A fatal error has been detected by the Java Runtime Environment:
[2020-09-24T18:37:08,632Z] #
[2020-09-24T18:37:08,632Z] #  Internal Error (/opt/mach5/mesos/work_dir/slaves/4076d11c-c6ed-4d07-84c1-4ab8d55cd975-S258829/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/45109e9b-b071-4bc0-ba14-7833a8cf019e/runs/957d8286-6650-4a04-812c-077cae1905a0/workspace/open/src/hotspot/share/gc/g1/g1Allocator.cpp:266), pid=20685, tid=20714
[2020-09-24T18:37:08,632Z] #  assert(!_g1h->is_humongous(desired_word_size)) failed: we should not be seeing humongous-size allocations in this path
[2020-09-24T18:37:08,632Z] #
[2020-09-24T18:37:08,632Z] # JRE version: Java(TM) SE Runtime Environment (16.0) (fastdebug build 16-internal+0-2020-09-24-1516275.gerard.ziemski.jdk)
[2020-09-24T18:37:08,632Z] # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-internal+0-2020-09-24-1516275.gerard.ziemski.jdk, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
[2020-09-24T18:37:08,632Z] # Problematic frame:
[2020-09-24T18:37:08,632Z] # V  [libjvm.so+0xadafbc]  G1Allocator::old_attempt_allocation(unsigned long, unsigned long, unsigned long*)+0x7c
[2020-09-24T18:37:08,632Z] #
[2020-09-24T18:37:08,632Z] # Core dump will be written. Default location: Core dumps may be processed with "/opt/core.sh %p" (or dumping to /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S89/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d888c2b0-32bf-4279-a1f6-59261f11567c/runs/605b7cec-5a7f-46da-8f93-512d671480a5/testoutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_sysdict/scratch/1/core.20685)
[2020-09-24T18:37:08,632Z] #
[2020-09-24T18:37:08,632Z] # An error report file with more information is saved as:
[2020-09-24T18:37:08,632Z] # /opt/mach5/mesos/work_dir/slaves/4728e7c1-7e67-490e-be0f-6bbf2a2f33db-S89/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/d888c2b0-32bf-4279-a1f6-59261f11567c/runs/605b7cec-5a7f-46da-8f93-512d671480a5/testoutput/test-support/jtreg_open_test_hotspot_jtreg_vmTestbase_nsk_sysdict/scratch/1/hs_err_pid20685.log
Comments
Contains JDK-8244778 but not JDK-8253261. Closing as dup of JDK-8253081.
19-10-2020
Closing out this issue for now since: - the issue has been reported with a failure that has been found in the CI and analyzed as being caused by JDK-8244778, the functionality intermittently disabled by JDK-8253261 a few days later and going to be fixed by JDK-8253081 - in similar runs by the reporter on the same day btree tests crashed with output caused by JDK-8254164 (i.e. bad oops, which can cause this message too) that has been fixed in the meantime - it is unknown what sources these builds were based on as the github branch has been removed, but it is somewhat likely that it did not contain JDK-8253261 and certainly did not contain JDK-8254164. Given all that there is not much to work with closing as CNR. If it occurs again, this can be reopened.
19-10-2020