#1001531
- Created on2013-02-21 15:28
- Reported by
- StatusFixed
- PriorityNormal (3)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
Internal error occurring when stopping the debugger in the middle of a debug session
I can't reproduce this consistently, but it happens to me quite frequently, and it's annoying because you get "nice" Eclipse errors dialog thrown to you.
All it takes is starting a debug session and then stopping it at some point. With some unlucky timing, you could get one of the following:
Below follow the two kind of errors I've seen:
All it takes is starting a debug session and then stopping it at some point. With some unlucky timing, you could get one of the following:
Below follow the two kind of errors I've seen:
- An internal error occurred during: "has children update".
com.sun.jdi.VMDisconnectedException: Got IOException from Virtual Machine
at org.eclipse.jdi.internal.connect.PacketSendManager.sendPacket(PacketSendManager.java:80)
at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:173)
at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:208)
at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:223)
at org.eclipse.jdi.internal.ObjectReferenceImpl.referenceType(ObjectReferenceImpl.java:477)
at scala.tools.eclipse.debug.model.ScalaObjectReference.hasVariables(ScalaValue.scala:142)
at org.eclipse.debug.internal.ui.model.elements.VariableContentProvider.hasChildren(VariableContentProvider.java:62)
at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider.updateHasChildren(ElementContentProvider.java:223)
at org.eclipse.debug.internal.ui.model.elements.ElementContentProvider$3.run(ElementContentProvider.java:200)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)- An internal error occurred during: "Label Job".
com.sun.jdi.VMDisconnectedException: Got IOException from Virtual Machine
at org.eclipse.jdi.internal.connect.PacketSendManager.sendPacket(PacketSendManager.java:80)
at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:173)
at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:208)
at org.eclipse.jdi.internal.MirrorImpl.requestVM(MirrorImpl.java:223)
at org.eclipse.jdi.internal.ObjectReferenceImpl.referenceType(ObjectReferenceImpl.java:477)
at scala.tools.eclipse.debug.model.ScalaObjectReference.getValueString(ScalaValue.scala:129)
at org.eclipse.debug.internal.ui.model.elements.VariableLabelProvider.getValueText(VariableLabelProvider.java:166)
at org.eclipse.debug.internal.ui.model.elements.VariableLabelProvider.getColumnText(VariableLabelProvider.java:112)
at org.eclipse.debug.internal.ui.model.elements.VariableLabelProvider.getLabel(VariableLabelProvider.java:92)
at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.getLabel(ElementLabelProvider.java:312)
at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider.retrieveLabel(ElementLabelProvider.java:215)
at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelUpdater.run(ElementLabelProvider.java:160)
at org.eclipse.debug.internal.ui.model.elements.ElementLabelProvider$LabelJob.run(ElementLabelProvider.java:74)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Leave a comment
on 2013-02-27 09:55 *
By Mirco Dotta
Just pointing out that this happens also with Scala IDE for Eclipse 3.0.0.rc1-2_10-201302252023-3951e3e org.scala-ide.sdt.feature.feature.group scala-ide.org
on 2013-02-27 09:57 *
By Mirco Dotta
And, even worse, as soon as I started a new debug session I got the exact same exception. Only resort was to restart Eclipse to get in a clean state.
on 2013-03-06 18:50 *
By Mirco Dotta
Assigned to set to Mirco Dotta
Status changed from New to Fixed
(In scala-ide:60df6af6ca83e83c8fee72146f19a064237df5b3) Comply to the debugger interfaces by wrapping JDI runtime exceptions
Several of the debugger interfaces we implement expect a ``DebugException`` to
be thrown when the called method fails to execute. Failure can occur, for
instance, when a debugger session is terminated by the user. Failing to wrap
the JDI runtime exception in a ``DebugException`` can prevent the debugger to
correctly work and the user is sometime forced to restart Eclipse.
``DebugException`` is a platform exception that is specially treated by
Eclipse.
If you wonder why do we have calls to ``safeStackFrameCalls`` in, for instance,
``ScalaStackFrame.getLineNumber``, the answer is: I don't think we need it. However,
since we are in RCs cycle for the 3.0 release, I want to minimize the changes in
this commit to avoid regressions.
Fix #1001531
Branch: master
Several of the debugger interfaces we implement expect a ``DebugException`` to
be thrown when the called method fails to execute. Failure can occur, for
instance, when a debugger session is terminated by the user. Failing to wrap
the JDI runtime exception in a ``DebugException`` can prevent the debugger to
correctly work and the user is sometime forced to restart Eclipse.
``DebugException`` is a platform exception that is specially treated by
Eclipse.
If you wonder why do we have calls to ``safeStackFrameCalls`` in, for instance,
``ScalaStackFrame.getLineNumber``, the answer is: I don't think we need it. However,
since we are in RCs cycle for the 3.0 release, I want to minimize the changes in
this commit to avoid regressions.
Fix #1001531
Branch: master
on 2013-03-06 19:25 *
By Mirco Dotta
(In scala-ide:be83fc8f7c40c71269d5e7315594896e6b85ab69) Comply to the debugger interfaces by wrapping JDI runtime exceptions
Several of the debugger interfaces we implement expect a ``DebugException`` to
be thrown when the called method fails to execute. Failure can occur, for
instance, when a debugger session is terminated by the user. Failing to wrap
the JDI runtime exception in a ``DebugException`` can prevent the debugger to
correctly work and the user is sometime forced to restart Eclipse.
``DebugException`` is a platform exception that is specially treated by
Eclipse.
If you wonder why do we have calls to ``safeStackFrameCalls`` in, for instance,
``ScalaStackFrame.getLineNumber``, the answer is: I don't think we need it. However,
since we are in RCs cycle for the 3.0 release, I want to minimize the changes in
this commit to avoid regressions.
Fix #1001531
(cherry picked from commit 60df6af6ca83e83c8fee72146f19a064237df5b3)
Branch: release/scala-ide-3.0.x
Several of the debugger interfaces we implement expect a ``DebugException`` to
be thrown when the called method fails to execute. Failure can occur, for
instance, when a debugger session is terminated by the user. Failing to wrap
the JDI runtime exception in a ``DebugException`` can prevent the debugger to
correctly work and the user is sometime forced to restart Eclipse.
``DebugException`` is a platform exception that is specially treated by
Eclipse.
If you wonder why do we have calls to ``safeStackFrameCalls`` in, for instance,
``ScalaStackFrame.getLineNumber``, the answer is: I don't think we need it. However,
since we are in RCs cycle for the 3.0 release, I want to minimize the changes in
this commit to avoid regressions.
Fix #1001531
(cherry picked from commit 60df6af6ca83e83c8fee72146f19a064237df5b3)
Branch: release/scala-ide-3.0.x
on 2013-06-05 08:56 *
By Mirco Dotta
(In scala-ide:60df6af6ca83e83c8fee72146f19a064237df5b3) Comply to the debugger interfaces by wrapping JDI runtime exceptions
Several of the debugger interfaces we implement expect a ``DebugException`` to
be thrown when the called method fails to execute. Failure can occur, for
instance, when a debugger session is terminated by the user. Failing to wrap
the JDI runtime exception in a ``DebugException`` can prevent the debugger to
correctly work and the user is sometime forced to restart Eclipse.
``DebugException`` is a platform exception that is specially treated by
Eclipse.
If you wonder why do we have calls to ``safeStackFrameCalls`` in, for instance,
``ScalaStackFrame.getLineNumber``, the answer is: I don't think we need it. However,
since we are in RCs cycle for the 3.0 release, I want to minimize the changes in
this commit to avoid regressions.
Fix #1001531
Branch: platform/juno
Several of the debugger interfaces we implement expect a ``DebugException`` to
be thrown when the called method fails to execute. Failure can occur, for
instance, when a debugger session is terminated by the user. Failing to wrap
the JDI runtime exception in a ``DebugException`` can prevent the debugger to
correctly work and the user is sometime forced to restart Eclipse.
``DebugException`` is a platform exception that is specially treated by
Eclipse.
If you wonder why do we have calls to ``safeStackFrameCalls`` in, for instance,
``ScalaStackFrame.getLineNumber``, the answer is: I don't think we need it. However,
since we are in RCs cycle for the 3.0 release, I want to minimize the changes in
this commit to avoid regressions.
Fix #1001531
Branch: platform/juno
on 2013-06-07 12:53 *
By Iulian Dragos
Fixed in version set to 3.0.1
Version changed from 2.1.0-nightly-210 to 3.0.0-210
Milestone changed from Current to 3.0.1