RFR: 8287982: Concurrent implicit attach from native threads crashes VM

David Holmes dholmes at openjdk.org
Tue Jun 21 07:13:41 UTC 2022


On Thu, 16 Jun 2022 13:34:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If several native threads attach to the VM at around the same time, and before any threads get an automatically generated name are created, then the VM may crash attempting to access the thread status. The issue exists for native threads that attach explicitly with JNI AttachCurrentThread without a thread name, or native threads that attach implicitly by using a function pointer to do an up call.
> 
> The issue that raises its head periodically is that native threads that JNI attach do the initializaiton of the Thread object in the context of the attaching thread. Great care must be taken because Java code is executing in the context of a Thread that is not fully initialized. The right thing is probably to create the Thread object in another thread, using the service thread has been mentioned. The issue at this time arises when two or more native threads attempt to attach without thread names at around the same time. The first thread that needs an automatically generated name triggers the loading and initialization of a helper class.  If there are other threads attaching at the same time then they may have to wait on the monitor which can trigger the crash because the field holder with the thread status is not created at this time. Crashes in monitor enter and notify have been observed. Coleen has changed this code so that linking and initialization uses a mutex (JDK-8288064) so
  this specific crash doesn't duplicate in the main line. The short term fix for openjdk/jdk19 is to reorder the initialization so that field holder with the thread status is created before setting the name.
> 
> Creating a jtreg test with the conditions to duplicate this issue is complicated. The jtreg main wrapper creates the main thread with an automatically generated thread name before it runs the test main method. This is the reason that the test needs to launch a new VM with the right setup to exercise both explicit and implicit attach.

Looks good.

And I confirmed that the VM code will correctly handle a null name from the current Java thread.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/28


More information about the core-libs-dev mailing list