RFR: 8014218: test/java/util/logging/DrainFindDeadlockTest.java failing intermittently (original) (raw)

Daniel Fuchs daniel.fuchs at oracle.com
Mon Jun 17 17:36:30 UTC 2013

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

More information about the core-libs-dev mailing list