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

[Andreas Eriksson]

Could you try with jdk8 or jdk7?
The fix should be exactly the same, and if it works one of those it 
should work on all of them.

/Andreas

On 2014-02-24 15:48, Dmitry Samersoff wrote:
> 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
>