Looks good! Thanks, /Staffan
On 27 feb 2013, at 00:54, Daniel D. Daugherty <[email protected]> wrote: > Greetings, > > I have a fix to make deadlock detection a little more robust in the case > of being unable to find the JavaThread associated with an object lock: > > 8007476 assert(the_owner != NULL) failed: Did not find owning Java > thread for lock word address > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007476 > https://jbs.oracle.com/bugs/browse/JDK-8007476 > > Yes, I know that's not supposed to happen, but if and when it does happen, > it would be good to be able to diagnose the VM to try and figure out what > the heck happened. > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8007476-webrev/0-hsx25/ > > There is some sample output in the bug report that shows both regular > deadlock detection output and the proposed modified deadlock detection > output. > > Thanks, in advance, for any comments, suggestions or questions. > > Dan > > P.S. > Yes, I've included a bit of tweaking to JVM/TI code to deal with > invalid assertion failures that are discussed in the following bug: > > 6786879 Race in jvmti GetObjectMonitorUsage could lead to crashes > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6786879 > https://jbs.oracle.com/bugs/browse/JDK-6786879 > > However, I haven't tried to address all the races that are discussed > in that bug including the race in the call to > JvmtiEnv::is_thread_fully_suspended() where the underlying call to > JavaThread::wait_for_ext_suspend_completion() can crash on lock exit. > Yikes, that one is nasty.
