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.spit...@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
