Community
Participate
Working Groups
Build ID: Build id: M20060921-0945 Steps To Reproduce: 1. As multi threading problem no easy way to reproduce 2. Provided information and stack trace should allow problem investigation More information: Scenario/Symptom: Remote debug session. Clicking into the Java Editor might lead to a disconnection to the remote VM. Severity major although obviously a rare problem, because it makes debugging impossible in affected scenarios. We were confronted with a debug scenario in which the problem was reproducable within minutes. This allowed following finding: Involved classes org.eclipse.jface.text.TextViewerHoverManager org.eclipse.jdt.internal.debug.ui.JavaDebugHover org.eclipse.jdi.internal.connect.PacketReceiveManager What happens is: The TextViewerHoverManager in the Java Editor tries to compute hover information content in a seperated Thread. While debugging the JavaDebugHover is used. The implementation tries to recieves information from remote VM. By clicking in the Java Editor a TextEvent is created. As a result the TextViewerHoverManager tries to force the termination of the current hover information computation by interrupting the related thread. If in this moment the JavaDebugHover is receiving remote information waiting in PacketReceiveManager the PacketReceiveManager disconnects the VM connection. See attached text file for related stack trace and related code snippets.
Created attachment 57153 [details] Stack Trace / Code Snippets
Thanks for reporting this finding! See bug 134684. This could make many people happy.
Created attachment 57185 [details] patch Patch for 3.2.2 org.eclipse.jdt.debug plug-in
Created attachment 57186 [details] plug-in replacement Replacement plug-in to test. Please delete your old org.eclipse.jdt.debug plug-in when using this to ensure that this plug-in is used.
Note that the replacement plug-in must be unzipped.
Trying your plugin replacement...: I went to the respective place in the code nine times (in three debug sessions) and then tried to reproduce the problem (usually 1-2 times, sometimes three times were sufficient to provoke it). But everything worked fine. Crosschecking without your fixed plugin it instantly failed again the first time I tried. I'd say this looks very good. Thanks a lot!
Created attachment 57851 [details] updated patch This is an updated patch. When a "wait for reply" is interrupted, the wait "breaks" and treats it the same as a timeout. When the reply packet is eventually received, we just discard it.
Marking as 3.2.2 candidate as this seems to be a large problem for some developers (see bug 134684).
CC'ing McQ and Philippe for 3.2.2 approval. The fix is a trivial, one-liner, with low risk. The problem was inadvertently introduced with the fix to bug 49115. We should only disconnect when the entire 'receive' thread is interrupted, not when a individual request is interrupted.
+1
(Released fix to HEAD/3.3)
Released to 3.2.2. Requested re-build.
Please verify, Mike (Rennie).
verified
*** Bug 134684 has been marked as a duplicate of this bug. ***
