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

[Chris Plummer]

On 8/28/16 6:14 PM, David Holmes wrote:
> 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.
It it correct to say that Dmitry is fixing a bug exposed by JDK-8134103, 
or that he is temporarily working around something that is not a true 
bug, but is indirectly caused by JDK-8134103. I'm not sure, but the 
answer will dictate the correct course of action here.

Chris
>
> 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
>>>
>>