RFR: 8014218: test/java/util/logging/DrainFindDeadlockTest.java failing intermittently

[Mandy Chung]

On 6/17/2013 10:36 AM, Daniel Fuchs wrote:
> On 6/17/13 7:11 PM, Mandy Chung wrote:
>> FYI. Staffan has a fix in hotspot for JDK-8016304 the ThreadMXBean issue
>> [1].
>
> Thanks Mandy.
>
> Yes I saw that. I will wait for Staffan's fix - revert my changes, and
> run the test again - and see what I get.

Perhaps you could pull his change into your local repo and verify if it 
resolves this issue.

Mandy

>
> Alternatively I could now modify the test to try & detect JDK-8016304
> too and throw an exception pointing at 8016304 if the thread ids
> returned by findDeadlockedThread do not seem to indicate a deadlock.
>
> -- daniel
>
>>
>> Thanks
>> Mandy
>> [1]
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-June/010194.html 
>>
>>
>>
>> On 6/17/2013 6:21 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a webrev for fixing
>>> 8014218: test/java/util/logging/DrainFindDeadlockTest.java failing
>>> intermittently
>>>
>>> <http://cr.openjdk.java.net/~dfuchs/JDK-8014218/webrev.00/>
>>>
>>> Without the fix - it's quite easy to make the test fail - especially
>>> if you copy paste the @run line a few times.
>>>
>>> This test is supposed to detect a deadlock in Logger initialization,
>>> but it detects too many false positive.
>>> An analysis of stack traces that the test dumps when it fails shows
>>> that there is actually no deadlock, since one of the two supposed
>>> deadlock threads is RUNNABLE.
>>>
>>> However - this - I think - indicates a bug in
>>> ThreadMXBean.findDeadlockedThreads().
>>>
>>> I have rewritten the test to sanitize the results before
>>> and after calling ThreadMXBean.findDeadlockedThreads().
>>>
>>> Namely - the test will call ThreadMXBean.findDeadlockedThreads()
>>> only if the two threads it monitors are simultaneously blocked
>>> (obtained by examining ThreadMXBean.getThreadInfo(long[])), and
>>> will verify that all threads found in deadlock by
>>> ThreadMXBean.findDeadlockedThreads() are indeed blocked.
>>>
>>> Now - I'm not sure whether this is a good thing or not:
>>>
>>> pros: it makes it possible to run this test again - and have a greater
>>>       confidence that if it fails it's because of a genuine deadlock,
>>>       which is desirable.
>>>
>>> cons: it 'hides' a possible bug in ThreadMXBean.findDeadlockedThreads()
>>>       as it appears the test was testing
>>>       ThreadMXBean.findDeadlockedThreads() more than (or as much
>>>       as) it was testing the Logger implementation.
>>>
>>> Does it make sense to push this fix and log a bug against ThreadMXBean?
>>> Or should I instead plan to add this test to the problem list
>>> (and re-qualify the bug as an issue in ThreadMXBean)?
>>>
>>> guidance appreciated!
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>
>>
>