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

Dmitry Samersoff dmitry.samersoff at oracle.com
Mon Feb 24 06:48:11 PST 2014


(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.


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.

More information about the hotspot-runtime-dev mailing list