andygrove commented on issue #238: URL: https://github.com/apache/arrow-java/issues/238#issuecomment-6550607089
This still happens in the current Windows CI job, and I think the cause is `TestEmptyArrowBuf.testEmptyArrowBuf`, which writes past the end of a native allocation. From 2026-08-25 to 2026-10-31 it caused 21 of the 38 failures of "AMD64 Windows Server 2022 Java JDK 17" (about 7% of runs in October), on `main`, on Dependabot PRs and on unrelated PRs. All 20 tests in `arrow-memory-netty` pass, and then surefire reports: ``` [INFO] Arrow Memory - Netty ............................... FAILURE [ERROR] ExecutionException Error occurred in starting fork, check output in log ``` Example on `main`: https://github.com/apache/arrow-java/actions/runs/41178662172/job/124471369915 The exit code in the original report, -1073740940, is `0xC0000374` (`STATUS_HEAP_CORRUPTION`), so Windows is killing the test JVM because its native heap is corrupt. On Windows, surefire now runs each test class in its own JVM (`reuseForks=false`). The crash therefore happens when that JVM exits, and this error path does not print the exit code. The JVM that dies is the one running `TestEmptyArrowBuf`. When the Develocity extension logs `Connection reset`, it does so right after that class finishes, after the other concurrent fork has already exited. `testEmptyArrowBuf` builds a 1024-byte `ArrowBuf` over `new PooledByteBufAllocatorL().empty.memoryAddress()` and writes 10 bytes through it. That address belongs to Netty's `EmptyByteBuf`, which is backed by `ByteBuffer.allocateDirect(0)`. The JDK satisfies that with an 8-byte `malloc`, because `Unsafe.allocateMemory` rounds up to 8. So the test writes 2 bytes past the end of the allocation. On 64-bit Windows an 8-byte heap block has no slack, so those bytes land on the next block's header. The overrun reproduces on macOS if `malloc` is interposed so that 8-byte allocations end at a guard page. `testEmptyArrowBuf` then fails with `java.lang.InternalError: a fault occurred in a recent unsafe memory access operation`. Backing the buffer with real memory from the test's own allocator fixes it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
