RFR: 8289919: [test] LoadLibraryUnloadTest.java failed with "Failed to unload native library"

[Jaikiran Pai]

On Tue, 12 Jul 2022 20:00:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test `java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnloadTest.java`
> Fails intermittently when expected output from a subprocess is not found.
> 
> I suspect a race between the Cleaner that is going to call JNI_OnUnload (in NativeLibraries.java:377) when the ClassLoader is no longer referenced and the test code that exits as soon as it detects that the p.Class1 is no longer referenced.
> 
> The proposed fix is to create a canary object referenced by the native library and released when the library is unloaded.
> The Java side of the test provides the canary object and uses a WeakReference to wait for it to be released.
> When released the child process exits and the driver test will find all of the output it expects.

Hello Roger,

> and the test code that exits as soon as it detects that the p.Class1 is no longer referenced.

Looking at the `LoadLibraryUnload` test, the `clazz` against which the `WeakReference` is being made in that test, gets updated in a loop https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java#L113 and thus the `WeakReference` happens to be against the last loop iteration's `clazz` https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/ClassLoader/loadLibraryUnload/LoadLibraryUnload.java#L149

>From what I understand of that test code, this `clazz` instance against which the `WeakReference` is being created, may not be the right one, since it isn't guaranteed that the classloader of this `clazz` is the one which "won" the attempt to load the native library. Do you think this (too) might be playing a role in this intermittent failure?


(It looks like a RFR mail didn't get generated for this one due to the missing issue description in the title of this PR)

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

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