RFR 8160892: VM warning: WaitForMultipleObjects timed out
Ivan Gerasimov
ivan.gerasimov at oracle.com
Wed Jul 6 23:09:56 UTC 2016
Thanks Daniel!
I'll rearrange comments as you suggest.
With kind regards,
Ivan
On 07.07.2016 0:21, Daniel D. Daugherty wrote:
> On 7/6/16 10:57 AM, Ivan Gerasimov wrote:
>> Hello!
>>
>> When fixing JDK-8069048 a potential race was overlooked:
>> 1) Thread A wants to call _endthreadex() and registers itself,
>> 2) Thread B wants to call exit(), takes its turn and raises the flag
>> `process_exiting`,
>> 3) Thread A continues, and gets captured in the loop at 4020, in
>> SuspendThread(GetCurrentThread()),
>> 4) Now, the thread B will have to wait for all the registered
>> threads, including the thread A, which will never wake up.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8160892
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8160892/00/webrev/
>
> src/os/windows/vm/os_windows.cpp
> Just to make sure the race is clear (in my mind at least):
>
> Thread A
> - executes if-block at L3913-3968; in particular it
> registers itself on L3957
> - executes if-block at L4017-4027; in the old code,
> the thread would block for ever in L4022-4026; in
> the new code, the thread will only block if it did
> not register itself.
>
> Thread B:
> - executes if-block at L3906-3910 and succeeds in
> setting the process_exiting flag
> - executes if-block at L3969-4012; in particular
> Thread B calls WaitForMultipleObjects() on L3994;
> in the old code, WaitForMultipleObjects() times
> out because Thread A is blocked.
>
> L3963: registered_itself = true;
> L3964: }
> L3965:
> L3966: // The current exiting thread has stored its handle
> in the array, and now
> L3967: // should leave the critical section before calling
> _endthreadex().
> The existing comment on L3966-3967 belongs after L3963 and before
> L3964, i.e., at the end of the else-block.
>
> If you agree with moving the comment on L3966-3967, then
> consider this next request:
>
> L3959: warning("DuplicateHandle failed (%u) in %s: %d\n",
> L3960: GetLastError(), __FILE__, __LINE__);
>
> Please consider adding the following comment after the warning:
>
> // We can't register this thread (no more handles) so this thread
> // may be racing with a thread that is calling exit(). If the
> thread
> // that is calling exit() has managed to set the process_exiting
> // flag, then this thread will be caught in the SuspendThread()
> // infinite loop below which closes that race. A small timing
> // window remains before the process_exiting flag is set, but it
> // is only exposed when we are out of handles.
>
> L4021: // don't let the current thread proceed to exit() or
> _endthreadex()
> Clarify comment: 'current thread'
> -> 'current unregistered thread'
>
> Very nice and very quick job in finding this race!
>
> Thumbs up on what you have since my comments are only related
> to moving/adding comments.
>
> Dan
>
>
>>
>> With kind regards,
>> Ivan
>>
>
>
More information about the serviceability-dev
mailing list