On Tue, 29 Nov 2022 15:40:53 GMT, Jorn Vernee <jver...@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
