JDK-8235346 : [Redo] 8235247: WorkerDataArray leaks C heap memory for associated work items
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2019-12-04
  • Updated: 2020-01-31
  • Resolved: 2019-12-06
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 14
14 b27Fixed
Related Reports
Relates :  
Description
The following test fails in the JDK14 CI:

gtest/GTestWrapper.java

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
----------System.err:(37/2554)----------

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.
Comments
gtest pass
31-01-2020

URL: https://hg.openjdk.java.net/jdk/jdk/rev/f55c453cef06 User: tschatzl Date: 2019-12-06 08:50:35 +0000
06-12-2019

JDK-8235341 fixes the API issue.
04-12-2019

The problem is a bug in the gtest, still assuming that there is no ownership of the sub-item WorkerDataArrays. I.e. both the main WorkerDataArray and the sub-WorkerDataArray are members of WorkerDataArrayTest; as the sub-WorkerDataArray is linked to the main one, both the destructor of the main WorkerDataArray and the destructor of WorkerDataArrayTest free its members.
04-12-2019

[~tschatzl] - This test failure might be related to your fix for JDK-8235247. Can you please take a look?
04-12-2019

This JDK14 CI job set includes the fix for: JDK-8235247 WorkerDataArray leaks C heap memory for associated work items so it's like that fix is related.
04-12-2019

Seeing this test fail on all platforms.
04-12-2019