#1001585
- Created on2013-03-10 09:09
- Reported by
- StatusFixed
- PriorityNormal (3)
- Assigned to
- Milestone
- Plan Level-
- Due Date-
Variables view in debugger doesn't show values
Using eclipse Juno, 2.10 ide (Scala IDE for Eclipse 3.0.0.rc2-2_10-201303062050-ccdb811).
When debugging, the variables view doesn't show the values of variables. Clicking a variable shows the following exception in the value window:
exception while invoking toString(): null
scala.tools.eclipse.debug.model.ScalaObjectReference.jdiInvokeMethod(ScalaValue.scala:172)
scala.tools.eclipse.debug.model.HasMethodInvocation$$anonfun$invokeMethod$2.apply(ScalaDebugElement.scala:141)
scala.tools.eclipse.debug.model.HasMethodInvocation$$anonfun$invokeMethod$2.apply(ScalaDebugElement.scala:135)
scala.util.control.Exception$Catch.apply(Exception.scala:102)
scala.tools.eclipse.debug.model.HasMethodInvocation$class.invokeMethod(ScalaDebugElement.scala:135)
scala.tools.eclipse.debug.model.ScalaObjectReference.invokeMethod(ScalaValue.scala:137)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$.computeDetail(ScalaDebugModelPresentation.scala:55)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$.computeDetail(ScalaDebugModelPresentation.scala:31)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$$anon$1.run(ScalaDebugModelPresentation.scala:88)
org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Also, can't change the value of variables - the "change value" option in the right click menu is disabled.
When debugging, the variables view doesn't show the values of variables. Clicking a variable shows the following exception in the value window:
exception while invoking toString(): null
scala.tools.eclipse.debug.model.ScalaObjectReference.jdiInvokeMethod(ScalaValue.scala:172)
scala.tools.eclipse.debug.model.HasMethodInvocation$$anonfun$invokeMethod$2.apply(ScalaDebugElement.scala:141)
scala.tools.eclipse.debug.model.HasMethodInvocation$$anonfun$invokeMethod$2.apply(ScalaDebugElement.scala:135)
scala.util.control.Exception$Catch.apply(Exception.scala:102)
scala.tools.eclipse.debug.model.HasMethodInvocation$class.invokeMethod(ScalaDebugElement.scala:135)
scala.tools.eclipse.debug.model.ScalaObjectReference.invokeMethod(ScalaValue.scala:137)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$.computeDetail(ScalaDebugModelPresentation.scala:55)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$.computeDetail(ScalaDebugModelPresentation.scala:31)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$$anon$1.run(ScalaDebugModelPresentation.scala:88)
org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
Also, can't change the value of variables - the "change value" option in the right click menu is disabled.
Leave a comment
I think this may be the same issue reported in #1001586. Basically, there was a very silly regression between 3.0.0-RC1 and RC2, and the Scala debugger in RC2 is pretty much completely unusable (NullPointerException are being thrown as soon as you expand any variable in the debugger view). The ticket I linked has already been fixed and I'm rebuilding the nightlies. Would you have the time to install the 3.0.x nightly and check if the issue you reported is still there? I'd really appreciate it (the update site for 3.0.x nightly for Eclipse Juno is scala-ide.dreamhosters.com/nightly/scala-ide-scala-ide-3.0.x-juno-2.10.1-SNAPSHOT).
About your second question, "change value" is not yet supported by the Scala Debugger. I've created a ticket #1001587 (star the ticket if you want to follow progress on that).
About your second question, "change value" is not yet supported by the Scala Debugger. I've created a ticket #1001587 (star the ticket if you want to follow progress on that).
on 2013-03-12 03:29 *
By rotem.hermon
I've installed the nightly from the URL you provided and still getting the same exception:
exception while invoking toString(): null
scala.tools.eclipse.debug.model.ScalaObjectReference.jdiInvokeMethod(ScalaValue.scala:172)
scala.tools.eclipse.debug.model.HasMethodInvocation$$anonfun$invokeMethod$2.apply(ScalaDebugElement.scala:141)
scala.tools.eclipse.debug.model.HasMethodInvocation$$anonfun$invokeMethod$2.apply(ScalaDebugElement.scala:135)
scala.util.control.Exception$Catch.apply(Exception.scala:102)
scala.tools.eclipse.debug.model.HasMethodInvocation$class.invokeMethod(ScalaDebugElement.scala:135)
scala.tools.eclipse.debug.model.ScalaObjectReference.invokeMethod(ScalaValue.scala:137)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$.computeDetail(ScalaDebugModelPresentation.scala:55)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$.computeDetail(ScalaDebugModelPresentation.scala:31)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$$anon$1.run(ScalaDebugModelPresentation.scala:88)
org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
plugin details: Scala IDE for Eclipse 3.0.0.nightly-2_10-201303120433-326daaf org.scala-ide.sdt.feature.feature.group scala-ide.org
exception while invoking toString(): null
scala.tools.eclipse.debug.model.ScalaObjectReference.jdiInvokeMethod(ScalaValue.scala:172)
scala.tools.eclipse.debug.model.HasMethodInvocation$$anonfun$invokeMethod$2.apply(ScalaDebugElement.scala:141)
scala.tools.eclipse.debug.model.HasMethodInvocation$$anonfun$invokeMethod$2.apply(ScalaDebugElement.scala:135)
scala.util.control.Exception$Catch.apply(Exception.scala:102)
scala.tools.eclipse.debug.model.HasMethodInvocation$class.invokeMethod(ScalaDebugElement.scala:135)
scala.tools.eclipse.debug.model.ScalaObjectReference.invokeMethod(ScalaValue.scala:137)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$.computeDetail(ScalaDebugModelPresentation.scala:55)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$.computeDetail(ScalaDebugModelPresentation.scala:31)
scala.tools.eclipse.debug.model.ScalaDebugModelPresentation$$anon$1.run(ScalaDebugModelPresentation.scala:88)
org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
plugin details: Scala IDE for Eclipse 3.0.0.nightly-2_10-201303120433-326daaf org.scala-ide.sdt.feature.feature.group scala-ide.org
on 2013-03-12 04:02 *
By Mirco Dotta
@rotem.hermon You are right! (And thanks for trying out the nightly). Turns out this is a bug we didn't know about, and it only happens if you use Eclipse Juno. I'll investigate. Only workaround at the moment is using the plain old Java debugger... :(
on 2013-03-12 04:04 *
By rotem.hermon
OK, will wait for a fix.
on 2013-03-13 04:15 *
By Mirco Dotta
Assigned to set to Mirco Dotta
Status changed from Accepted to Fixed
(In scala-ide:2de89febce7f9fb36820838b83f9ebd05fb0409d) Workaround for NPE in debugger variable view when using Eclipse Juno
Unfortunately, the way we keep track of the currently selected thread in the
Scala debugger isn't robust enough. Currently, we rely on a selectionChanged
event to be sent when the Debug Perspective is opened. This worked fine with
Eclipse Indigo, but it's no longer working with Eclipse Juno.
The workaround is to look for the first suspended thread if
``ScalaDebugger.currentThread`` is null. This is far from being a proper fix,
but it doesn't look like we have many alternatives. The Java debugger
implementation seem to be using a DebugContextProvider/Manager/Event/Listener
to know the thread associated to each variable. But using the debug context
classes would require some import work, so it would be preferable to delay this
for after the 3.0.0 final release.
The workaround was suggested by @skyluc, and he believes the only issue this
could lead to is visibility issues due to invoking a method call on the wrong
thread (in case more than one is suspended), and hence the executing thread may
see some stale values. Not an issue to be taken lightly.
Fix #1001585
backport to release/3.0.x
Branch: master
Unfortunately, the way we keep track of the currently selected thread in the
Scala debugger isn't robust enough. Currently, we rely on a selectionChanged
event to be sent when the Debug Perspective is opened. This worked fine with
Eclipse Indigo, but it's no longer working with Eclipse Juno.
The workaround is to look for the first suspended thread if
``ScalaDebugger.currentThread`` is null. This is far from being a proper fix,
but it doesn't look like we have many alternatives. The Java debugger
implementation seem to be using a DebugContextProvider/Manager/Event/Listener
to know the thread associated to each variable. But using the debug context
classes would require some import work, so it would be preferable to delay this
for after the 3.0.0 final release.
The workaround was suggested by @skyluc, and he believes the only issue this
could lead to is visibility issues due to invoking a method call on the wrong
thread (in case more than one is suspended), and hence the executing thread may
see some stale values. Not an issue to be taken lightly.
Fix #1001585
backport to release/3.0.x
Branch: master
on 2013-03-13 04:15 *
By Mirco Dotta
(In scala-ide:3fdc4109eef024627c0ac14c5d5808341e342ebe) Workaround for NPE in debugger variable view when using Eclipse Juno
Unfortunately, the way we keep track of the currently selected thread in the
Scala debugger isn't robust enough. Currently, we rely on a selectionChanged
event to be sent when the Debug Perspective is opened. This worked fine with
Eclipse Indigo, but it's no longer working with Eclipse Juno.
The workaround is to look for the first suspended thread if
``ScalaDebugger.currentThread`` is null. This is far from being a proper fix,
but it doesn't look like we have many alternatives. The Java debugger
implementation seem to be using a DebugContextProvider/Manager/Event/Listener
to know the thread associated to each variable. But using the debug context
classes would require some import work, so it would be preferable to delay this
for after the 3.0.0 final release.
The workaround was suggested by @skyluc, and he believes the only issue this
could lead to is visibility issues due to invoking a method call on the wrong
thread (in case more than one is suspended), and hence the executing thread may
see some stale values. Not an issue to be taken lightly.
Fix #1001585
backport to release/3.0.x
(cherry picked from commit 2de89febce7f9fb36820838b83f9ebd05fb0409d)
Branch: release/scala-ide-3.0.x
Unfortunately, the way we keep track of the currently selected thread in the
Scala debugger isn't robust enough. Currently, we rely on a selectionChanged
event to be sent when the Debug Perspective is opened. This worked fine with
Eclipse Indigo, but it's no longer working with Eclipse Juno.
The workaround is to look for the first suspended thread if
``ScalaDebugger.currentThread`` is null. This is far from being a proper fix,
but it doesn't look like we have many alternatives. The Java debugger
implementation seem to be using a DebugContextProvider/Manager/Event/Listener
to know the thread associated to each variable. But using the debug context
classes would require some import work, so it would be preferable to delay this
for after the 3.0.0 final release.
The workaround was suggested by @skyluc, and he believes the only issue this
could lead to is visibility issues due to invoking a method call on the wrong
thread (in case more than one is suspended), and hence the executing thread may
see some stale values. Not an issue to be taken lightly.
Fix #1001585
backport to release/3.0.x
(cherry picked from commit 2de89febce7f9fb36820838b83f9ebd05fb0409d)
Branch: release/scala-ide-3.0.x
on 2013-06-05 02:56 *
By Mirco Dotta
(In scala-ide:2de89febce7f9fb36820838b83f9ebd05fb0409d) Workaround for NPE in debugger variable view when using Eclipse Juno
Unfortunately, the way we keep track of the currently selected thread in the
Scala debugger isn't robust enough. Currently, we rely on a selectionChanged
event to be sent when the Debug Perspective is opened. This worked fine with
Eclipse Indigo, but it's no longer working with Eclipse Juno.
The workaround is to look for the first suspended thread if
``ScalaDebugger.currentThread`` is null. This is far from being a proper fix,
but it doesn't look like we have many alternatives. The Java debugger
implementation seem to be using a DebugContextProvider/Manager/Event/Listener
to know the thread associated to each variable. But using the debug context
classes would require some import work, so it would be preferable to delay this
for after the 3.0.0 final release.
The workaround was suggested by @skyluc, and he believes the only issue this
could lead to is visibility issues due to invoking a method call on the wrong
thread (in case more than one is suspended), and hence the executing thread may
see some stale values. Not an issue to be taken lightly.
Fix #1001585
backport to release/3.0.x
Branch: platform/juno
Unfortunately, the way we keep track of the currently selected thread in the
Scala debugger isn't robust enough. Currently, we rely on a selectionChanged
event to be sent when the Debug Perspective is opened. This worked fine with
Eclipse Indigo, but it's no longer working with Eclipse Juno.
The workaround is to look for the first suspended thread if
``ScalaDebugger.currentThread`` is null. This is far from being a proper fix,
but it doesn't look like we have many alternatives. The Java debugger
implementation seem to be using a DebugContextProvider/Manager/Event/Listener
to know the thread associated to each variable. But using the debug context
classes would require some import work, so it would be preferable to delay this
for after the 3.0.0 final release.
The workaround was suggested by @skyluc, and he believes the only issue this
could lead to is visibility issues due to invoking a method call on the wrong
thread (in case more than one is suspended), and hence the executing thread may
see some stale values. Not an issue to be taken lightly.
Fix #1001585
backport to release/3.0.x
Branch: platform/juno
on 2013-08-27 07:57 *
By Iulian Dragos
Version changed from 3.0.0-RC2-210 to 3.0.1-210
Milestone set to 3.0.2
on 2013-08-27 07:58 *
By Iulian Dragos
Eclipse version changed from Indigo - Eclipse 3.7 to Juno - Eclipse 4.2
In scala-ide:2deb50b0160d8e0b21a32ba76ff7eda9d35b9238 Uses new debug view selection support
In Eclipse 4.x, a new way to follow the current selection in the debug view was implemented,
as debug specific support.
The old way was slightly broken, and was no more working for selection changes not triggered
by the user. A temporary fix was implemented in Scala 3.0.x, to support Eclipse 3.x and 4.x.
This commit replace the old code and the fix by a solution using the new support.
Fixes #1001585
Need to be backported in 3.0.x-juno.
In scala-ide:262e2d961cf6790ac9e33721335da4e7333b8b86 Uses new debug view selection support
In Eclipse 4.x, a new way to follow the current selection in the debug view was implemented,
as debug specific support.
The old way was slightly broken, and was no more working for selection changes not triggered
by the user. A temporary fix was implemented in Scala 3.0.x, to support Eclipse 3.x and 4.x.
This commit replace the old code and the fix by a solution using the new support.
Fixes #1001585
(cherry picked from commit 22238324758784a8bc9cdb1db6ce5f134b3420c3)