RFR: JDK-8033696: "assert(thread != NULL) failed: just checking" due to Thread::current() and JNI pthread interaction

[Andreas Eriksson]

Thanks Gerard.

Could you add some logging to the destructor to check it is not called 
more than once?

Regards,
Andreas

On 2014-02-17 20:17, Gerard Ziemski wrote:
> I will volunteer to take a look at it this week.
>
>
> cheers
>
> On 2/16/2014 6:35 PM, David Holmes wrote:
>> Hi Andreas,
>>
>> As per previous discussions I think this is okay. Normally we don't 
>> flag changes with the bug ID but in this case I think it is obscure 
>> enough to warrant that.
>>
>> I've convinced myself that the order of destructor invocations 
>> doesn't matter, as long as a simple linear traversal is done that 
>> checks the values, nulls them and invokes the destructor (if any). 
>> However if the implementation did this in two passes:
>>
>> find all non-null values with destructors;
>> execute all destructors;
>> rinse-repeat
>>
>> then our destructor would be called multiple times in the normal 
>> case, as well as the bad case.
>>
>> So we are relying on the linux and bsd implementation behaviour. We 
>> already know that neither seem to follow the POSIX spec on this - 
>> hence the bug. You've verified how linux behaves. But now we need to 
>> be clear how different BSDs will behave - at least FreeBSD and OSX. 
>> Hopefully someone from runtime can assist with the analysis on BSD.
>>
>> Thanks,
>> David
>>
>> On 11/02/2014 2:21 AM, Andreas Eriksson wrote:
>>> Hi,
>>>
>>> Could I please get reviews for this change.
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8033696
>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8033696/webrev.00/
>>> Mail discussion:
>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2014-February/010759.html 
>>>
>>>
>>>
>>> Summary:
>>> JNI code is using pthread_key_create with a destructor to detach the
>>> thread from the JVM when the thread is exiting.
>>> For some flavors of Linux and BSD the JVM is also using the
>>> pthread_key_create, to store the Thread::current() value in a thread
>>> local storage.
>>> Since the thread local storage containing the thread pointer is erased
>>> (by pthread) before the JNI destructor runs, we run detachCurrentThread
>>> on a thread that has NULL as current thread.
>>> This fix uses a destructor for the thread pointer that restores the
>>> value, so that the JNI destructor can run detachCurrentThread 
>>> successfully.
>>> More info in JBS.
>>>
>>> Testing:
>>> Native code regtest attached to JBS tested on Linux, but not on Mac
>>> since I don't have access to one.
>>> JPRT ran without a problem.
>>>
>>> Regards,
>>> Andreas
>>
>