Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8235346

[Redo] 8235247: WorkerDataArray leaks C heap memory for associated work items


    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:
    • Verification:


      The following test fails in the JDK14 CI:


      Here's a snippet from the test log:

      [----------] 4 tests from BasicWorkerDataArrayTest
      [ RUN ] BasicWorkerDataArrayTest.sum_test_test_vm
      [24.815s][warning][malloc,free ] ## nof_mallocs = 8681751, nof_frees = 8867108
      [24.815s][warning][malloc,free ] ## memory stomp:
      [24.815s][warning][malloc,free ] GuardedMemory(0x00007ffeebc0ead0) base_addr=0x0000000002669080 tag=0x0000000000000000 user_size=24 user_data=0x00000000026690a0
      [24.815s][warning][malloc,free ] Header guard @0x0000000002669080 is BROKEN
      [24.815s][warning][malloc,free ] Trailer guard @0x00000000026690b8 is OK
      [24.815s][warning][malloc,free ] User data appears to have been freed
      # To suppress the following error report, specify this argument
      # after -XX: or in .hotspotrc: SuppressErrorAt=/os.cpp:654
      # A fatal error has been detected by the Java Runtime Environment:
      # Internal Error (open/src/hotspot/share/runtime/os.cpp:654), pid=8055, tid=8055
      # fatal error: memory stomping error
      # JRE version: Java(TM) SE Runtime Environment (14.0+26) (fastdebug build 14-ea+26-1237)
      # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 14-ea+26-1237, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
      # Problematic frame:
      # V [libjvm.so+0x15dc4d7] verify_memory(void*)+0x287
      # 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/6e54f4af-e606-43b0-80ce-0a482a5988b6-S247/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/0dfb427e-1c90-4633-a173-e628f83d75aa/runs/f3c18855-8da9-483b-968c-838f6e4300bb/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_common/scratch/1/core.8055)
      # An error report file with more information is saved as:
      # /opt/mach5/mesos/work_dir/slaves/6e54f4af-e606-43b0-80ce-0a482a5988b6-S247/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/0dfb427e-1c90-4633-a173-e628f83d75aa/runs/f3c18855-8da9-483b-968c-838f6e4300bb/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_common/scratch/1/hs_err_pid8055.log
      # If you would like to submit a bug report, please visit:
      # https://bugreport.java.com/bugreport/crash.jsp
      # The crash happened outside the Java Virtual Machine in native code.
      # See problematic frame for where to report the bug.
      Current thread is 8055
      Dumping core ...

      [2019-12-04T17:10:33.724995Z] Waiting for completion for process 8055
      [2019-12-04T17:10:33.725247Z] Waiting for completion finished for process 8055

      Here's the crashing thread's stack:

      --------------- T H R E A D ---------------

      Current thread (0x0000000002068000): JavaThread "main" [_thread_in_native, id=8055, stack(0x00007ffeebb10000,0x00007ffeebc10000)]

      Stack: [0x00007ffeebb10000,0x00007ffeebc10000], sp=0x00007ffeebc0eac0, free space=1018k
      Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
      V [libjvm.so+0x15dc4d7] verify_memory(void*)+0x287
      V [libjvm.so+0x15e0b4f] os::free(void*)+0x5f
      V [libjvm.so+0x51bde1] BasicWorkerDataArrayTest_sum_test_test_vm_Test::~BasicWorkerDataArrayTest_sum_test_test_vm_Test()+0x171
      V [libjvm.so+0x395559] testing::TestInfo::Run()+0xc9
      V [libjvm.so+0x395665] testing::TestCase::Run()+0xa5
      V [libjvm.so+0x396104] testing::internal::UnitTestImpl::RunAllTests()+0x464
      V [libjvm.so+0x3961f4] testing::UnitTest::Run()+0x64
      V [libjvm.so+0x3a0836] runUnitTestsInner(int, char**)+0x336
      V [libjvm.so+0x3a0a55] runUnitTests+0xd5
      C [gtestLauncher+0x5e2]

      This is a tier1 test failure so starting this bug at P2.
      I think the BasicWorkerDataArray tests belong to the
      GC team so starting this bug in hotspot/gc for initial triage.


          Issue Links



              • Assignee:
                tschatzl Thomas Schatzl
                dcubed Daniel Daugherty
              • Votes:
                0 Vote for this issue
                4 Start watching this issue


                • Created: