RFR: 8290231: java/foreign/malloc/TestMixedMallocFree.java crashed in JDK19 ATR run

Maurizio Cimadamore mcimadamore at openjdk.org
Tue Nov 29 19:10:23 UTC 2022


On Tue, 29 Nov 2022 15:40:53 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This test allocates on the native side with `malloc`, and then tries to free that memory on the Java side. The library that we look up on the Java side is either ucrtbase.dll, or msvcrt.dll as a fallback if we don't find it. The fact that we're seeing this crash likely means that the test machine doesn't have ucrtbase.dll, but it does have a newer standard runtime library other than msvcrt.dll (one of the msvcp*.dll libraries).
> 
> So, what can happen is: the native code in the test ends up being linked against this newer runtime library. We allocate using the newer runtime library's `malloc` function. Look up `free` from Java, don't find ucrtbase.dll so fall back to msvcrt.dll. Call `free` from msvcrt.dll which is not the right one, and then crash due to the allocator mismatch.
> 
> ---
> 
> I think we should just remove this test. In practice, we can not guarantee that native code is linked against the same dll as the one we pick to be the default library (for instance, the native code could have been linked against an older dll, even while ucrtbase.dll is present on the system).
> 
> Trying to mach up the 2 libraries was important when we had public `allocateMemory` and `freeMemory` functions, but those were removed from the API.
> 
> Using matching allocate & free pairs, which some of the other tests do, still works.

Looks good - I agree this test isn't useful anymore

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11417


More information about the core-libs-dev mailing list