RFR: JDK-8204994: SA might fail to attach to process with "Windbg Error: WaitForEvent failed"

serguei.spitsyn at oracle.com serguei.spitsyn at oracle.com
Fri May 29 03:35:28 UTC 2020


Hi Alex,

It'd be nice to reduce noise from such intermittent issues and also get 
rid of such bugs in the future.
My gut feeling is that we just significantly reduced a probability of 
this failure in something
like an order of magnitude but it will still happens once in a month or 
a half of year.
This issue should go away completely with 3 or 4 iterations.
The price is not high as the 3rd iteration is going to be rare and the 
4th should never happen.
Also, it would not increase complexity.

But no pressure, you are to decide.
I'm just sharing my opinion.

Thanks,
Serguei


On 5/28/20 17:04, Alex Menkov wrote:
> Hi Serguei,
>
> With my testing 2nd call always succeeded, but I was able to reproduce 
> the case only 3 times with my test runs.
> I can implement the loop, but number of retries is anyway an arbitrary 
> value.
>
> --alex
>
> On 05/28/2020 15:44, serguei.spitsyn at oracle.com wrote:
>> Hi Alex,
>>
>> It looks good in general.
>>
>> +static HRESULT WaitForEvent(IDebugControl *ptrIDebugControl) {
>> + // see JDK-8204994: sometimes WaitForEvent fails with E_ACCESSDENIED,
>> + // but succeeded on 2nd call.
>> + HRESULT hr = ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, 
>> INFINITE);
>> + if (hr == E_ACCESSDENIED) {
>> + // yield current thread use of a processor (short delay).
>> + SwitchToThread();
>> + hr = ptrIDebugControl->WaitForEvent(DEBUG_WAIT_DEFAULT, INFINITE);
>> + }
>> + return hr;
>> +}
>>
>>
>> Can the ptrIDebugControl->WaitForEvent fail with E_ACCESSDENIED twice 
>> and succeed on third call?
>> Would it better to make it a loop with more retry attempts?
>>
>> Thanks,
>> Serguei
>>
>>
>> On 5/27/20 13:54, Alex Menkov wrote:
>>> Hi all,
>>>
>>> please review the fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8204994
>>> webrev:
>>> http://cr.openjdk.java.net/~amenkov/jdk15/WinDbg_WaitForEvent/webrev/
>>>
>>> --alex
>>



More information about the serviceability-dev mailing list