Bug ID: JDK-8320366 gtest/GTestWrapper.java failed os_linux.glibc_mallinfo_wrapper

Versions (Unresolved/Resolved/Fixed)

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 25
25Resolved

The following test failed in the JDK22 CI:

gtest/GTestWrapper.java

Here's a snippet from the log file:

[ RUN      ] os_linux.decoder_get_source_info_valid_overflow_minimal_vm
[       OK ] os_linux.decoder_get_source_info_valid_overflow_minimal_vm (0 ms)
[ RUN      ] os_linux.glibc_mallinfo_wrapper_vm
open/test/hotspot/gtest/runtime/test_os_linux.cpp:428: Failure
Expected: (mi.fordblks) < (2 * G), actual: 2446131008 vs 2147483648

[  FAILED  ] os_linux.glibc_mallinfo_wrapper_vm (0 ms)
[----------] 12 tests from os_linux (3 ms total)

[----------] 4 tests from ostream
[ RUN      ] ostream.stringStream_dynamic_start_with_internal_buffer_vm
[       OK ] ostream.stringStream_dynamic_start_with_internal_buffer_vm (0 ms)

<snip>

----------System.err:(10/590)----------
java.lang.AssertionError: gtest execution failed; exit code = 2. the failed tests: [os_linux::glibc_mallinfo_wrapper_vm]
	at GTestWrapper.main(GTestWrapper.java:98)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
	at java.base/java.lang.Thread.run(Thread.java:1570)

JavaTest Message: Test threw exception: java.lang.AssertionError
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.AssertionError: gtest execution failed; exit code = 2. the failed tests: [os_linux::glibc_mallinfo_wrapper_vm]

This was fixed with the fix for JDK-8320859
24-07-2025
RT Triage: there are no documented sightings of this issue since Nov 2023. Closing as CNR.
10-12-2024
I propose to hold off changing this limit until https://bugs.openjdk.org/browse/JDK-8320859 is fixed. Triggering the 2G limit can be seen as early warning indicator that something is off with malloc footprint.
28-11-2023
Note: fordblk is libc memory retention, basically. I logged libc state and identified `BufferNodeAllocatorTest.stress_free_list_allocator_vm` as a test accumulating over 800 MB in libc footprint retention. The rest of the tests come to about 50MB (meaning, commenting this one test out decreases retention at the end of the gtest run to 50mb). Looking at NMT peak values, this test accumulates a malloc footprint of ~1.5GB. This is unaffected by heap size. I opened JDK-8320859 to track. I also opened JDK-8320836 to limit heap size for gtest runs.
28-11-2023
The comment is wrong, it should say "less than". Odd, because I would not have thought that we accumulate more than 2G retained footprint in glibc during the course of a gtest run. I'll take a look. The reason I don't want to switch this off simply is that I want to make sure we don't have some leak somewhere. >2GB seems excessive.
28-11-2023
+#ifdef __GLIBC__ +TEST_VM(os_linux, glibc_mallinfo_wrapper) { + // Very basic test. Call it. That proves that resolution and invocation works. + os::Linux::glibc_mallinfo mi; + bool did_wrap = false; + + os::Linux::get_mallinfo(&mi, &did_wrap); + + void* p = os::malloc(2 * K, mtTest); + ASSERT_NOT_NULL(p); + + // We should see total allocation values > 0 + ASSERT_GE((mi.uordblks + mi.hblkhd), 2 * K); + + // These values also should exceed some reasonable size. + ASSERT_LT(mi.fordblks, 2 * G); + ASSERT_LT(mi.uordblks, 2 * G); + ASSERT_LT(mi.hblkhd, 2 * G); + + os::free(p); +} +#endif // __GLIBC__ This test was added with JDK-8296784. From the man page, I see no reason that mi.forblks should be less than 2G. Or is it greater than 2G as the comment says.
27-11-2023
[RT triage] ILW=MLM=P4. Moving to P3 because this is a tier1 test failure.
20-11-2023

Duplicate :	JDK-8320859 - gtest high malloc footprint caused by BufferNodeAllocator stress test
Relates :	JDK-8318966 - Some methods make promises about Java array element alignment that are too strong
Relates :	JDK-8320859 - gtest high malloc footprint caused by BufferNodeAllocator stress test
Relates :	JDK-8320836 - jtreg gtest runs should limit heap size