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

Jiawei Tang jwtang at openjdk.org
Thu Aug 8 02:21:39 UTC 2024


On Wed, 7 Aug 2024 12:13:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I was able to reproduce this `NoClassDefFoundError` in this new test locally. I will take a look to see if I can figure out what's going on.
>
> I looked into this locally and this is a (known) bug in jtreg https://bugs.openjdk.org/browse/CODETOOLS-7902847.
> 
> What's happening here is that the tests are launched using make test TEST=test/hotspot/jtreg/:tier1_serviceability. One of those tests is the (pre-existing unrelated to this PR) AgentWithVThreadTest. That test has a `@compile AgentWithVThread.java AgentWithVThreadTest.java`. This triggers compilation of those classes and also any referenced classes in those 2 classes. One such class happens to be the test library's jdk.test.lib.Utils. This is a test library class (used/referenced indirectly in that test). jtreg ends up issuing a javac command with destination directory as the AgentWithVThreadTest's test specific work directory:
> 
> 
> -d build/macosx-aarch64/test-support/jtreg_test_hotspot_jtreg_tier1_serviceability/classes/0/serviceability/jvmti/vthread/premain/AgentWithVThreadTest.d
> 
> 
> So the `jdk.test.lib.Utils.class` (along with other classes) file ends up being compiled to `build/macosx-aarch64/test-support/jtreg_test_hotspot_jtreg_tier1_serviceability/classes/0/serviceability/jvmti/vthread/premain/AgentWithVThreadTest.d/jdk/test/lib/Utils.class`. During this compilation, the `jdk.test.lib.util.JavaAgentBuilder` doesn't get compiled because that class isn't referenced by AgentWithVThreadTest (neither directly or indirectly).
> 
> Then during the same test execution, jtreg notices a `@run` statement:
> 
> 
> @run driver jdk.test.lib.util.JavaAgentBuilder ....
> 
> 
> And to launch that run action, it first builds and compiles the jdk.test.lib.util.JavaAgentBuilder and since this is a test library class, jtreg ends up launching `javac` with a destination directory which is common/shared by multiple tests:
> 
> 
> -d build/macosx-aarch64/test-support/jtreg_test_hotspot_jtreg_tier1_serviceability/classes/0/test/lib
> 
> 
> Additionally, since this is being compiled in context of the AgentWithVThreadTest, jtreg also passes the test specific work directory (`build/macosx-aarch64/test-support/jtreg_test_hotspot_jtreg_tier1_serviceability/classes/0/serviceability/jvmti/vthread/premain/AgentWithVThreadTest.d`) as the classpath to the javac command. So effectively, this compilation ends up finding the `jdk.test.lib.Utils.class` in the test specific directory and doesn't recompile to the shared location. Since the `jdk.test.lib.util.JavaAgentBuilder` hasn't yet been compiled nor is located in the test specific work directory, javac ends up compiling it and placing it in the destinati...

I was inspired by [CODETOOLS-7901986](https://bugs.openjdk.org/browse/CODETOOLS-7901986). By adding `@build jdk.test.lib.Utils` all tests are passed. The GitHub Actions jobs are finished successfully, too. I hope I could get a final review now.

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

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


More information about the serviceability-dev mailing list