JDK-8348909 : [BACKOUT] Implement a better allocator for downcalls
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.lang.foreign
  • Affected Version: 25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • Submitted: 2025-01-29
  • Updated: 2025-02-21
  • Resolved: 2025-01-31
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
25 b09Fixed
Related Reports
Causes :  
JDK-8287788 - Implement a better allocator for downcalls
Relates :  
JDK-8350455 - Malloc errors when concurrently allocating and freeing memory.
Description
Absolutely nothing to go on:

----------System.out:(2/128)----------
NativeTestHelper::DEFAULT_RANDOM.seed = -997602716
Re-run with '-DNativeTestHelper.DEFAULT_RANDOM.seed=-997602716' to reproduce
----------System.err:(0/0)----------
----------rerun:(40/6765)*----------
...
result: Failed. Unexpected exit from test [exit code: 134]

Only odd thing is that dmesg shows:

[3150874.643914]: AMFI: Denying core dump for pid 29393 (java)AMFI: Denying core dump for pid 29393 (java)AMFI: Denying core dump for pid 29393 (java)AMFI: Denying core dump for pid 29393 (java)java[29393] Corpse allowed 1 of 5
Comments
Changeset: 77647421 Branch: master Author: Jorn Vernee <jvernee@openjdk.org> Date: 2025-01-31 16:49:03 +0000 URL: https://git.openjdk.org/jdk/commit/77647421c5b13738f6fa145bf30cbb9dd741e164
31-01-2025
The failure has also been seen on mac aarch64, so it doesn't seem to be x64 specific
31-01-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23391 Date: 2025-01-31 15:01:08 +0000
31-01-2025
[~jlamperth] Helped me get a stack trace, which I attached to issue. In particular, thread #31 looks suspicious: thread #31 frame #0: 0x00007ff80a454c6a libsystem_kernel.dylib`__sendto + 10 frame #1: 0x00007ff80a4bc787 libsystem_platform.dylib`_os_log_simple_send + 349 frame #2: 0x00007ff80a4bc618 libsystem_platform.dylib`__os_log_simple_offset + 294 frame #3: 0x00007ff80a4bc8b9 libsystem_platform.dylib`_os_log_simple_shim + 38 frame #4: 0x00007ff80a2ef4de libsystem_malloc.dylib`malloc_vreport + 543 frame #5: 0x00007ff80a304897 libsystem_malloc.dylib`malloc_zone_error + 178 frame #6: 0x00007ff80a2fd05d libsystem_malloc.dylib`nanov2_guard_corruption_detected + 34 frame #7: 0x00007ff80a2fc364 libsystem_malloc.dylib`nanov2_allocate_outlined + 385 frame #8: 0x00007ff80a2e20bd libsystem_malloc.dylib`nanov2_malloc + 526 frame #9: 0x000000010f35c674 libjvm.dylib`os::malloc(size=8, mem_tag=mtOther, stack=0x000070000787c390) at os.cpp:657:3 [opt] frame #10: 0x000000010f35c429 libjvm.dylib`os::malloc(size=8, mem_tag=mtOther) at os.cpp:625:10 [opt] frame #11: 0x000000011fe36bf2 frame #12: 0x000000011fe582c0 Looks like there's some heap corruption going on. Will back out the change, and investigate separately.
31-01-2025