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

Daniel Fuchs daniel.fuchs at oracle.com
Mon Jun 17 13:21:17 UTC 2013


Please find below a webrev for fixing
8014218: test/java/util/logging/DrainFindDeadlockTest.java failing 


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

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

More information about the core-libs-dev mailing list