Community
Participate
Working Groups
In non-stop, while running over a long operation (sleep) I saw this assert. I tracked it down to the fact that we didn't expect IExecutionDMData#getStateChangeReason to return null. However, in the case of non-stop, for threads that are currently running, the stateChangeReason is null. In fact, the PROP_STATE_CHANGE_REASON_KNOWN does check if the property PROP_STATE_CHANGE_REASON is null, but the assert did not. java.lang.AssertionError: unexpected state change reason: null at org.eclipse.cdt.dsf.debug.ui.viewmodel.launch.ExecutionContextLabelText.getPropertyValue(ExecutionContextLabelText.java:80) at org.eclipse.cdt.dsf.gdb.internal.ui.viewmodel.launch.GdbExecutionContextLabelText.getPropertyValue(GdbExecutionContextLabelText.java:32) at org.eclipse.cdt.dsf.ui.viewmodel.properties.LabelText.updateAttribute(LabelText.java:86) at org.eclipse.cdt.dsf.ui.viewmodel.properties.LabelColumnInfo.updateColumn(LabelColumnInfo.java:140) at org.eclipse.cdt.dsf.ui.viewmodel.properties.PropertiesBasedLabelProvider.updateLabel(PropertiesBasedLabelProvider.java:169) at org.eclipse.cdt.dsf.ui.viewmodel.properties.PropertiesBasedLabelProvider$1.handleCompleted(PropertiesBasedLabelProvider.java:120) at org.eclipse.cdt.dsf.concurrent.RequestMonitor$2.run(RequestMonitor.java:291) at org.eclipse.cdt.dsf.concurrent.ImmediateExecutor.execute(ImmediateExecutor.java:62) at org.eclipse.cdt.dsf.concurrent.RequestMonitor.done(RequestMonitor.java:289) at org.eclipse.cdt.dsf.ui.viewmodel.VMViewerUpdate.done(VMViewerUpdate.java:189) at org.eclipse.cdt.dsf.ui.viewmodel.properties.VMPropertiesUpdate.done(VMPropertiesUpdate.java:117) at org.eclipse.cdt.dsf.ui.viewmodel.update.AbstractCachingVMProvider.updateNode(AbstractCachingVMProvider.java:1120) at org.eclipse.cdt.dsf.ui.viewmodel.update.AbstractCachingVMProvider.update(AbstractCachingVMProvider.java:1055) at org.eclipse.cdt.dsf.ui.viewmodel.properties.PropertiesBasedLabelProvider.update(PropertiesBasedLabelProvider.java:124) at org.eclipse.cdt.dsf.debug.ui.viewmodel.launch.AbstractThreadVMNode.update(AbstractThreadVMNode.java:154) [...]
Created attachment 170423 [details] Suggested fix I suggest this fix to ExecutionContextLabelText. I think it is safe for RC3 but not essential either.
John, do you agree with this fix? If so, should we commit for RC3 or post Helios?
(In reply to comment #2) > John, do you agree with this fix? > If so, should we commit for RC3 or post Helios? Yes, though I would add a comment in the new block // running threads in non-stop mode have no state change reason
(In reply to comment #3) > (In reply to comment #2) > > John, do you agree with this fix? > > If so, should we commit for RC3 or post Helios? > > Yes, though I would add a comment in the new block > // running threads in non-stop mode have no state change reason Done and committed to HEAD. (with a slight rewording)
*** cdt cvs genie on behalf of mkhouzam *** Bug 314950: A null reason is valid in non-stop mode [*] ExecutionContextLabelText.java 1.8 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf.ui/src/org/eclipse/cdt/dsf/debug/ui/viewmodel/launch/ExecutionContextLabelText.java?root=Tools_Project&r1=1.7&r2=1.8