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

[Daniel Fuchs]

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.

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