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. ------------- Commit messages: - Remove MixedMallocFree test Changes: https://git.openjdk.org/jdk/pull/11417/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11417&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290231 Stats: 101 lines in 2 files changed: 0 ins; 101 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11417.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11417/head:pull/11417 PR: https://git.openjdk.org/jdk/pull/11417
