JDK-6293795 : Backend hangs when invokeMethod is called from a JDI eventHandler
  • Type: Bug
  • Component: core-svc
  • Sub-Component: debugger
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-07-02
  • Updated: 2010-12-08
  • Resolved: 2006-04-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u10Fixed 6 b83Fixed
Related Reports
Relates :  
JDK-6321448 - self-suspension with JVM-internal monitors and mutexes may not be needed
Description
See example in attached zip file.  
It has a debugger that starts a debuggee with two bkpts
set. The debuggee starts two threads.  When
a thread hits a bkpt, an invokeMethod is done.

I have seen two failure modes:
1.
- main thread just starts the two debuggee threads
  and then completes.  It issues a thread death
  event and then the commandLoop waits for a resume that never
  comes

- thread 2 is reporting a bkpt and is waiting for cmd complete lock
- thread 1 is posting method entry and has suspended itself under 
         JavaThread::handle_special_runtime_exit_condition(

 
2.  
- I think main thread exitted ok
- thread 1 has hit a bkpt and reported it.  The debugger does an invokeMethod
  on this thread.  It hangs trying to get the System.out
  monitor in a println call, because thread 2 has this monitor.
- thread 2 is under a println call so it has the monitor.  It
  is trying to post a method entry event and is blocked waiting
  for the threadLock (which thread 1 must hold, but I haven't
  been able to prove it).

I have seen some variations of this 2nd hang.
Needless to say, this doesn't happen everytime.  The testcase
does several iterations and it happens sooner or later.
This happens in 5.0 and 1.4.2 as well as mustang.



###@###.### 2005-07-02 07:54:57 GMT
Comments
SUGGESTED FIX See attached webrev.
24-04-2006
EVALUATION Three variations of hangs have been found. 1. The debugger sets bkpts in each thread, runs the debuggee, and when a bkpt is hit, does an invokeMethod, with INVOKEED_SINGLE_THREADED In this case, the following hang can occur: - debuggee thread t1 hits a bkpt - a SUSPEND_ALL is done - debuggee thread t2 is suspended while doing a println, ie, while holding the System.out lock - debugger gets the bkpt - debugger does the invokeMethod in thread t1 - the invokee does a println and hangs trying to get the System.out lock Thread t2 isn't going to be resumed and release the System.out lock until the debugger event handler resume it, which isn't going to occur until the invokeMethod finishes, which isn't going to occur until thread t2 has been resumed and releases the lock. This is not a JPDA bug. It is an example of the dangers of doing an invokeMethod, INVOKE_SINGLE_THREADED as warned about in the javadoc 2. To avoid the above hang, the testcase was changed to not use INVOKE_SINGLE_THREADED on the invokeMethod. Hangs still occur this way: - debuggee thread t1 hits a bkpt - a SUSPEND_ALL is done - debuggee threads t1 and t2 are suspended - debugger gets the bkpt - debugger does the invokeMethod in thread t1 - all threads are resumed - thread t2 hits its bkpt - threads t1 and t2 are suspended - the bkpt is sent to the front-end - the debugger's event handler never gets the breakpoint because it is still waiting for the invokeMethod to complete before it gets the next event. And the invokeMethod isn't going to complete until the debugger does a resume for the 2nd breakpoint. This isn't a JPDA bug either - it just demonstrates the dangers of doing things in the event handler that might prevent events from being handled. 3. To avoid the above hang, the test was changed so that the debugger's event handler disabled events before doing the invokeMethod and then enabled events after the invokeMethod completed. This allowed the test to run better than before, but hangs still occur. The hang is similar to that in 2. above, and that described in bug 6296125 JDI: Disabling an EventRequest can cause a multi-threaded debuggee to hang That bug was fixed by changing the JDI eventQueue.remove() method to notice when the EventSet only contains events whose corresponding requests have been disabled. In this case, the remove() method does an eventSet.resume(), if necessary, because no one else is going to. In this new hang, this fix isn't executed because the debugger eventHandler never calls eventQueue.remove() for the 2nd breakpoint because it is hung waiting for the invokeMethod to complete. Therefore, this _is_ a JPDA bug, and it is a variation of 6296125. It needs a fix similar to the fix for 6296125, but at a lower level in the the front-end event handling so that the eventSet.resume() will get done even if the debugger doesn't call eventQueue.remove(). It seems to me that the new fix should be in addition to the existing fix instead of replacing it. If we replace, then there will be a window between when the check is made for disabled events and when the debugger actually calls eventQueue.remove() during which the debugger could disable events, and the 6296125 hang will occur. *** (#1 of 1): [ UNSAVED ] ###@###.###
05-11-2005