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

[Dmitry Samersoff]

Andreas,

(CC'in Greg)

I'm not able to compile ojdk9 on FreeBSD (did some cleanup on fly but
stuck on NIO)

and it's seems like freebsd community don't have patches for JDK 9 yet.

-Dmitry

On 2014-02-24 16:51, Andreas Eriksson wrote:
> Great, thanks.
> 
> /Andreas
> 
> On 2014-02-24 13:15, Dmitry Samersoff wrote:
>> Andreas,
>>
>> I'll check it on FreeBSD 9.x
>>
>> -Dmitry
>>
>> On 2014-02-24 15:36, Andreas Eriksson wrote:
>>> Thanks Gerard.
>>>
>>> Do you know if there are any machines with FreeBSD or OpenBSD that I can
>>> test this on?
>>>
>>> Regards,
>>> Andreas
>>>
>>> On 2014-02-20 21:55, Gerard Ziemski wrote:
>>>> hi Andreas,
>>>>
>>>> Mac OS X appears to work similarly and the pthread_key destructor
>>>> appears to be only called once.
>>>>
>>>> So it appears that OS X also does not follow the POSIX spec, but even
>>>> if (when) it does in the future, the destructor will be called at most
>>>> PTHREAD_DESTRUCTOR_ITERATIONS times (which on Mac OS X is currently
>>>> set to 4), so if we keep our destructor as simple as it is we should
>>>> be OK.
>>>>
>>>> Thank you for the fix.
>>>>
>>>>
>>>> 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
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.