JDK-8350455 : Malloc errors when concurrently allocating and freeing memory.
  • Type: Bug
  • Component: core-libs
  • Affected Version: 25
  • Priority: P4
  • Status: Closed
  • Resolution: External
  • OS: os_x
  • CPU: generic
  • Submitted: 2025-02-20
  • Updated: 2025-11-21
  • Resolved: 2025-09-19
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.
Other
tbdResolved
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
The following test occasionally crashes with exit code 134:

    /*
     * @test
     * @modules java.base/jdk.internal.misc
     * @build TestVTStressHeap
     * @run main/othervm TestVTStressHeap
     */
    
    import jdk.internal.misc.Unsafe;
    
    import java.time.Duration;
    import java.util.Arrays;
    import java.util.stream.IntStream;
    
    import static java.time.temporal.ChronoUnit.SECONDS;
    
    public class TestVTStressHeap {
        private static final Unsafe U = Unsafe.getUnsafe();
    
        public static void main(String[] args) throws InterruptedException {
            Thread[] vThreads = IntStream.range(0, 1024).mapToObj(_ ->
                    Thread.ofVirtual().start(() -> {
                        while (!Thread.interrupted()) {
                            for (int i = 0; i < 1_000_000; i++) {
                                long addr = U.allocateMemory(Long.BYTES);
                                U.freeMemory(addr);
                            }
                            Thread.yield(); // make sure the driver thread gets a chance.
                        }
                    })).toArray(Thread[]::new);
            Thread.sleep(Duration.of(10, SECONDS));
            Arrays.stream(vThreads).forEach(Thread::interrupt);
        }
    }

When a core dump is produced, one of the threads will be inside __pthread_kill, with a stack that looks like this:

  thread #24, stop reason = signal SIGSTOP
    frame #0: 0x00007ff802ea61e2 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007ff802eddee6 libsystem_pthread.dylib`pthread_kill + 263
    frame #2: 0x00007ff802e04b45 libsystem_c.dylib`abort + 123
    frame #3: 0x00007ff802d1b752 libsystem_malloc.dylib`malloc_vreport + 888
    frame #4: 0x00007ff802d30a08 libsystem_malloc.dylib`malloc_zone_error + 183
    frame #5: 0x00007ff802d2907c libsystem_malloc.dylib`nanov2_guard_corruption_detected + 34
    frame #6: 0x00007ff802d2837f libsystem_malloc.dylib`nanov2_allocate_outlined + 385
    frame #7: 0x00007ff802d0e168 libsystem_malloc.dylib`nanov2_malloc + 529
    frame #8: 0x000000011025d174 libjvm.dylib`os::malloc(unsigned long, MemTag, NativeCallStack const&) + 404
    frame #9: 0x000000011025cf29 libjvm.dylib`os::malloc(unsigned long, MemTag) + 57
    frame #10: 0x0000000120cfc972
    frame #11: 0x0000000120d01f80

Or like this:

  thread #23, stop reason = signal SIGSTOP
    frame #0: 0x00007ff8052e41e2 libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x00007ff80531bee6 libsystem_pthread.dylib`pthread_kill + 263
    frame #2: 0x00007ff805242b45 libsystem_c.dylib`abort + 123
    frame #3: 0x00007ff805159752 libsystem_malloc.dylib`malloc_vreport + 888
    frame #4: 0x00007ff80515cb31 libsystem_malloc.dylib`malloc_report + 151
    frame #5: 0x0000000120fffc72
    frame #6: 0x000000012100508c

This issue has only been observed on mac (x64 & aarch64). It is unclear whether this is an issue in the JDK, or in the mac standard library implementation of malloc/free.
Comments
> Apple responded on that issue and asked us to try the macOS 26 Beta 2 version to see if it reproduces there. We have run this reproducer and some other tests on this version and the issue no longer reproduces. It appears that the issue has been fixed in macOS 26. I'll close this current issue once macOS 26 if officially released. Now that macos 26 has been released, I'm closing this issue as "External".
19-09-2025

> This turned out to be an issue unrelated to Java itself. So we have reported this to Apple along with a reproducer. Apple's feedback assitant id for this issue is FB16566672. Apple responded on that issue and asked us to try the macOS 26 Beta 2 version to see if it reproduces there. We have run this reproducer and some other tests on this version and the issue no longer reproduces. It appears that the issue has been fixed in macOS 26. I'll close this current issue once macOS 26 if officially released.
29-06-2025

This turned out to be an issue unrelated to Java itself. So we have reported this to Apple along with a reproducer. Apple's feedback assitant id for this issue is FB16566672.
23-02-2025

Hello Jorn, I suspect this is the same as what Per reported in https://bugs.openjdk.org/browse/JDK-8350375?
21-02-2025