On Thu, 8 Aug 2024 08:54:54 GMT, Jiawei Tang <jwt...@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
