RFR(S): 8163994: Nightly test crashed in jvmtiAllocate

David Holmes david.holmes at oracle.com
Mon Aug 29 01:14:19 UTC 2016


On 27/08/2016 7:35 AM, Chris Plummer wrote:
> Hi Dmitry,
>
> Although the fix is addressing the specific issue described in the bug,
> what about the general issue of referencing gdata after a call to
> cbEarlyVMDeath(). Do more references to gdata need to be protected?
>
> Also, is there the possibility of a multi-threading race condition here?
> Could gdata be cleared by another thread after it is checked?

Certainly. This really isn't fixing anything just adding a bailout check 
before the crashing code. We can still crash and not be any the wiser as 
to why.

Not sure I really see the point of doing this instead of closing this as 
a dup of JDK-8134103 and fixing things properly.

David

> thanks,
>
> Chris
>
> On 8/26/16 4:00 AM, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please review the fix.
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8163994/webrev.02/
>>
>> *Problem*
>>
>> Under some circumstances, when JVMTI_ERROR_WRONG_PHASE(112) is received,
>> jvmtiAllocate could be called after call to cbEarlyVMDeath.
>>
>> cbEarlyVMDeath set gdata->jvmti to NULL, so jvmtiAllocate crashes.
>>
>> The problem appears only once in nightly testing and I was not able to
>> reproduce it locally.
>>
>> *Solution*
>>
>> Guard added to jvmtiAllocate to get meaningful error message instead of
>> crash.
>>
>> These fix doesn't fix root cause - JVMTI_ERROR_WRONG_PHASE problem is
>> going to be addressed under JDK-8134103.
>>
>> -Dmitry
>>
>


More information about the serviceability-dev mailing list