RFR 8247966: runtime/logging/loadLibraryTest/LoadLibraryTest.java failed "RuntimeException: 'Unloaded library with handle' missing from stdout/stderr"

Harold Seigel harold.seigel at oracle.com
Tue Jun 23 21:00:48 UTC 2020


Thanks Dan!

Harold

On 6/23/2020 4:53 PM, Daniel D. Daugherty wrote:
> On 6/23/20 1:45 PM, Harold Seigel wrote:
>> Hi,
>>
>> Please review this small change to fix logging test 
>> LoadLibraryTest.java.  The fix prevents the main thread from 
>> terminating before the Cleaner thread has had a chance to unload 
>> native library "LoadLibraryClass".  It does this in the following way.
>>
>> Java has a restriction that a native library can only be loaded by 
>> one class loader.  The JDK is able to implement this restriction by 
>> synchronizing access to loading and unloading native libraries.  (See 
>> synchronization on static object loadedLibraryNames in 
>> jdk/internal/loader/NativeLibraries.java.) So, the code in the test 
>> that checks if the class that loaded the native library was unloaded, 
>> was changed to try to load the native library.  If it was able to 
>> load the native library then it knows that the Cleaner thread has 
>> finished unloading the library.  If not, it waits a little and checks 
>> again in a polling loop.
>>
>> Open Webrev: 
>> http://cr.openjdk.java.net/~hseigel/bug_8247966/webrev/index.html
>
> test/hotspot/jtreg/runtime/logging/loadLibraryTest/LoadLibraryTest.java
>     So in the bug report, we found the first unload library indicator 
> line:
>
>     > Class LoadLibraryClass was unloaded
>
>     and the test failed because we didn't find the second unload library
>     indicator line:
>
>     > Unloaded library with handle
>
>     Your fix makes the main() thread wait around until the library is
>     finished being unloaded by trying to load it again. I like it!
>
>     If we have a bug down the road where the test prints the
>     "Class LoadLibraryClass was unloaded" message, but doesn't finish
>     the library unload, then we'll timeout in the loop. I think that's
>     okay for an unlikely failure mode.
>
> Thumbs up.
>
> Dan
>
>>
>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8247966
>>
>> The modified test was tested on Linux-x64, Linux-aarch64, Windows, 
>> and Mac OS X and run 500+ times using Window-x64 fastdebug builds.
>>
>> Thanks, Harold
>>
>


More information about the hotspot-runtime-dev mailing list