Withdrawn: RFR: JDK-8245660: Try to recover from "Windbg Error: WaitForEvent failed" error

Alex Menkov alexey.menkov at oracle.com
Wed May 27 18:07:19 UTC 2020


The issue is closed as it's possible to test the solutions without 
pushing the change.

--alex

On 05/22/2020 17:27, Alex Menkov wrote:
> Hi Chris,
> 
> On 05/22/2020 17:12, Chris Plummer wrote:
>> Hi Alex,
>>
>> I think this is a good experiment, but I don't really see a reason to 
>> push the change and wait for a failure to pop up in CI testing. I 
>> think you should be able to get the data you are looking for with 
>> adhoc runs. I find it pretty easy to reproduce by just running all the 
>> SA tests about 100 times (maybe more). In fact it was so noisy for me 
>> when I was trying to reproduce some very rare x86 failures that I 
>> stopped doing the testing on windows and just stuck with osx and linux.
> 
> I thought it's quite hard to reproduce the issue. But I'll try to run 
> several times.
> 
>> Is there a reason the 2nd AttachProcess() does not re-fetch 
>> ptrIDebugControl_ID? Is it sure to be the same value as with the first 
>> attach?
> 
> It's just a native pointer saved in java field (initialized during 
> debugger COM object creation).
> No reason to re-fetch it.
> 
> --alex
> 
>>
>> thanks,
>>
>> Chris
>>
>> On 5/22/20 3:51 PM, Alex Menkov wrote:
>>> Hi all,
>>>
>>> Please review the fix for
>>> https://bugs.openjdk.java.net/browse/JDK-8245660
>>> webrev:
>>> http://cr.openjdk.java.net/~amenkov/jdk15/windbg_waitForEvent_try/webrev/ 
>>>
>>>
>>> This is temporary change to try different approaches to fix
>>> https://bugs.openjdk.java.net/browse/JDK-8204994 (SA might fail to 
>>> attach to process with "Windbg Error: WaitForEvent failed")
>>>
>>> --alex
>>>
>>


More information about the serviceability-dev mailing list