On Wed, 1 Nov 2023 18:35:00 GMT, Roger Riggs <[email protected]> wrote:
>> `TestLoadLibraryDeadlock.java` test runs `LoadLibraryDeadlock` and wait for
>> 5 seconds and then grab the output. Then run `jcmd` to dump the thread
>> stacks in case there is a deadlock. The test ignores and swallows any
>> exception which makes it hard to diagnose test issues.
>>
>> This PR simplifies the test to use `jdk.test.lib.process.ProcessTools` to
>> launch `LoadLibraryDeadlock` test so that the output and error will be
>> captured in the same way as other tools are run by this test. Also update
>> the test to propagate exceptions where appropriate. This hopes to collect
>> more information to diagnose the issue if this test fails next time.
>
> test/jdk/java/lang/ClassLoader/loadLibraryDeadlock/TestLoadLibraryDeadlock.java
> line 115:
>
>> 113: Collections.addAll(commands, java);
>> 114: Collections.addAll(commands, Utils.getTestJavaOpts());
>> 115: Collections.addAll(commands, command);
>
> The prose description talks about using ProcessTools, but the runCommand code
> doesn't use ProcessTools.createTestJavaProcessBuilder. It could save a few
> steps.
`runCommand` sets the working directory whereas
`ProcessTools.createTestJavaProcessBuilder` does not. Either way is okay with
me if we want to use `createTestJavaProcessBuilder` (which will set the VM
options).
+ ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder("-cp",
+ "a.jar"
+ classPathSeparator +
+ "b.jar"
+ classPathSeparator +
+ "c.jar",
+
"-Djava.library.path=" + testLibraryPath,
+
"LoadLibraryDeadlock")
+ .directory(new File(testClassPath));
+ OutputAnalyzer outputAnalyzer = ProcessTools.executeCommand(pb)
+ .shouldHaveExitValue(0);
or set the class path to the explicit path of the JAR files.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/16459#discussion_r1379206601
