(S) RFR: 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread

[David Holmes]

On 4/08/2016 12:07 AM, Frederic Parain wrote:
> David,
>
> Interesting twist about JavaThreads returning to their plain
> Thread nature before dying.

Yes that was quite baffling for a while :)

> Fix looks good to me.

Thanks for the review Fred!

David

> Fred
>
> On 08/02/2016 09:13 PM, David Holmes wrote:
>> webrev: http://cr.openjdk.java.net/~dholmes/8159461/webrev/
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8159461
>>
>> The suspend/resume signal (SR_signum) is never sent to a thread once it
>> has started to terminate. On one platform (SuSE 12) we have seen what
>> appears to be a "stuck" signal, which is only delivered when the
>> terminating thread restores its original signal mask (as if
>> pthread_sigmask makes the system realize there is a pending signal - we
>> already check the signal was not blocked). At this point in the thread
>> termination we have freed the osthread, so the the SR_handler would
>> access deallocated memory. In debug builds we first hit an assertion
>> that the current thread is a JavaThread or the VMThread - that assertion
>> fails, even though it is a JavaThread, because we have already executed
>> the ~JavaThread destructor and inside the ~Thread destructor we are a
>> plain Thread not a JavaThread.
>>
>> The fix was to make a small adjustment to the thread termination process
>> so that we delete the SR_lock before calling os::free_thread(). In the
>> SR_handler() we can then use a NULL check of SR_lock() to indicate the
>> thread has terminated and we return.
>>
>> While only seen on Linux I took the opportunity to apply the fix on all
>> platforms and also cleaned up the code where we were using
>> Thread::current() unsafely in a signal-handling context.
>>
>> Testing: regular tier 1 (JPRT)
>>          Kitchensink (in progress)
>>
>> As we can't readily reproduce the problem I tested this by having a
>> terminating thread raise SR_signum directly from within the ~Thread
>> destructor.
>>
>> Thanks,
>> David