RFR: 8337331: crash: pinned virtual thread will lead to jvm crash when running with the javaagent option [v11]

[Jaikiran Pai]

On Thu, 8 Aug 2024 08:54:54 GMT, Jiawei Tang <jwtang at openjdk.org> wrote:

>> `@clean jdk.test.lib.util.JavaAgentBuilder` cannot solve the problem. 
>> I find that the reason why `AgentWithVThreadTest.java` can pass is that when compiling `AgentWithVThread.java`, it uses jdk.test.lib.Utils through `import` (`import jdk.test.lib.process.ProcessTools;`, `import jdk.test.lib.Utils;` is in the ProcessTools.java), so the test dir contains jdk.test.lib.Utils. However, my new testcase doesn't use it. 
>> <img src=https://github.com/user-attachments/assets/cd80f76e-24b4-463b-bcfd-4b4ba32374cd width=300 />
>> 
>> I tryed add `import jdk.test.lib.Utils;` in my testcase, it can pass.
>> <img src=https://github.com/user-attachments/assets/cfb10e17-23ae-47f4-b0da-e107fe06c711 width=400 />
>> 
>> 
>> If I only run the new testcase, it can pass and the work dir look like this:
>> <img src=https://github.com/user-attachments/assets/ade018b0-c0b0-4675-b3a0-784b4ef82b78 width=300 />
>> 
>> If I run `AgentWithVThread.java` and then `TestPinCaseWithCFLH.java`, the Utils.class is missed in test/lib/jdk/test/lib:
>> <img src=https://github.com/user-attachments/assets/83dd910c-ff61-4c06-9ccc-256b2d0ccf1f width=300 />
>
> A stable way to reproduce the problem: run AgentWithVThread.java and then TestPinCaseWithCFLH.java.
> 
> 
> jtreg -v:error,fail -jdk:{JDKPATH} ./test/hotspot/jtreg/serviceability/jvmti/vthread/premain/AgentWithVThreadTest.java
> jtreg -v:error,fail -jdk:{JDKPATH} ./test/hotspot/jtreg/serviceability/jvmti/vthread/TestPinCaseWithCFLH/TestPinCaseWithCFLH.java

When I proposed the `@clean` option, I had tried it locally and that had worked for me and I wasn't able to reproduce that issue anymore locally. However, looking at the failed GitHub actions job with the `@clean` option, I see this:



#section:clean
----------messages:(5/232)----------
command: clean jdk.test.lib.util.JavaAgentBuilder
reason: User specified action: run clean jdk.test.lib.util.JavaAgentBuilder 
started: Thu Aug 08 07:40:24 UTC 2024
finished: Thu Aug 08 07:40:24 UTC 2024
elapsed time (seconds): 0.0
----------rerun:(2/367)*----------
cd /Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_hotspot_jtreg_tier1_serviceability/scratch/0 && \\
rm -f /Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_hotspot_jtreg_tier1_serviceability/classes/0/serviceability/jvmti/vthread/TestPinCaseWithCFLH/TestPinCaseWithCFLH.d/jdk/test/lib/util/JavaAgentBuilder.class
result: Passed. Clean successful

#section:build
----------messages:(5/194)----------
command: build jdk.test.lib.util.JavaAgentBuilder
reason: Named class compiled on demand
started: Thu Aug 08 07:40:24 UTC 2024
finished: Thu Aug 08 07:40:24 UTC 2024
elapsed time (seconds): 0.0
result: Passed. All files up to date

So jtreg in its clean action appears to have only deleted the test specific work directory:


rm -f /Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_hotspot_jtreg_tier1_serviceability/classes/0/serviceability/jvmti/vthread/TestPinCaseWithCFLH/TestPinCaseWithCFLH.d/jdk/test/lib/util/JavaAgentBuilder.class

and of course that `JavaAgentBuilder.class` won't be there and is instead present in the shared directory at `/Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_hotspot_jtreg_tier1_serviceability/classes/0/test/lib`. So jtreg didn't clean up the shared directory location and let that class stay around which effectively meant the `@clean` ended up being a no-op.

I have run out of ideas to introduce a proper workaround here. The right fix of course needs to happen in jtreg, which I will see if there are ways to implement it there.

For now, it looks like the `@build jdk.test.lib.Utils` approach you used and made the test pass is the only way to make this consistently pass.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20373#discussion_r1709023985