RFR: 8330303: Crash: assert(_target_jt == nullptr || _target_jt->vthread() == target_h()) failed

Serguei Spitsyn sspitsyn at openjdk.org
Tue Apr 23 22:07:29 UTC 2024


On Tue, 23 Apr 2024 19:05:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is a simple fix of three similar asserts.
>> The `_target_jt->jvmti_vthread()` has to be used instead of `_target_jt->vthread()`. 
>> The `_target_jt->vthread()` can be outdated in some specific contexts as shown in the `hs_err` stack trace.
>> 
>> I've seen similar issue and already fixed it in this fragment of code:
>> 
>> class GetCurrentLocationClosure : public JvmtiUnitedHandshakeClosure {
>>   . . .
>>   void do_vthread(Handle target_h) {
>>     assert(_target_jt == nullptr || !_target_jt->is_exiting(), "sanity check");
>>     // use jvmti_vthread() as vthread() can be outdated
>>     assert(_target_jt == nullptr || _target_jt->jvmti_vthread() == target_h(), "sanity check");
>>     . . .
>> 
>> The issue above was fixed by replacing `_target_jt->vthread()` with `_target_jt->jvmti_vthread()`.
>> 
>> There are three places which need to be fixed the same way:
>>  - `GetSingleStackTraceClosure::do_vthread(Handle target_h)`
>>  - `SetForceEarlyReturn::do_vthread(Handle target_h)`
>>  - `UpdateForPopTopFrameClosure::do_vthread(Handle target_h)`
>> 
>> Testing:
>>  - Run mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2079:
> 
>> 2077: void
>> 2078: GetSingleStackTraceClosure::do_vthread(Handle target_h) {
>> 2079:   // use jvmti_vthread() as vthread() can be outdated
> 
> The only reason I can see of why just using vthread() doesn't work is because of the case where we are in a temporary switch to carrier thread. So maybe change comment to be: "use jvmti_vthread() instead of vthread() as target could have temporary changed identity to carrier thread (see VirtualThread.switchToCarrierThread)". Same in the other places.

Thank you for the suggestion. Will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18806#discussion_r1576959637


More information about the serviceability-dev mailing list