Community
Participate
Working Groups
Unfortunately I do not know how to reproduce this outside of our DSF-based debugger and I cannot publish the sources. I will try to create a code that reproduces this issue. Our debugger is designed to debug code that contains hundreds of threads. Thus Debug view only shows several VMContexts and when the user uses Down arrow to manually select thread that does not yet have VMContext. I.e. imagine our debug view may look like + Launch Configuration ++ Process +++ Thread 1 +++ Thread 2 +++ Thread 3 +++ Thread 4 Everything works as expected when the user selects Thread 1 and uses arrow down to select threads 2-4. What we see is that if the user presses Down to go to Thread 5 Debug view will properly scroll down, instantiate the VM context - but IDebugContextListeners recieve a notification that the selection is empty (i.e. variables are emptied, etc.) I set a breakpoint to LaunchView:439 (it is selectionChanged method of the fTreeViewerSelectionChangedListener) and confirmed that it looks like empty selection is coming from a tree.
Hi Eugene, Most likely when you select thread 5, the viewer selects an item for which the element is not known yet. Then when the element is retrieved from the model it should send a new selection containing it. Do you see this, or is the empty selection the last event that is sent?
Breakpoint in LaunchView:439 is hit only once - and IDebugContextListener only gets notification about empty selection. Note that IDebugContextListener are always called 4 times, whether with empty selection or not.
So to be clear, the end user experience is that the variables views are blank and source is not positioned, correct?
Pawel, you are correct, the problem manifestation is empty dependent views. Please note that "vanilla" CDT does not populate Registers/Variables/etc. when thread is selected - it requires a stack frame selected. This is the behavior specific to our product (though we feel strongly we should discuss it with CDT team once our product is released). It is not possible to reproduce the problem with CDT UI.
The threads are retrieved lazily from the model, so I don't understand what is special about your product. It would be best if you could hack the PDA example debugger to reproduce the problem. Short of that, if you turn on tracing in the viewer with the following options, we may get some clues as to what's happening: org.eclipse.debug.ui/debug = true org.eclipse.debug.ui/debug/viewers/model = false org.eclipse.debug.ui/debug/viewers/viewer = false org.eclipse.debug.ui/debug/viewers/deltas = true org.eclipse.debug.ui/debug/viewers/contentProvider = true org.eclipse.debug.ui/debug/viewers/updateSequence = false org.eclipse.debug.ui/debug/contextlaunching = false org.eclipse.debug.ui/debug/launchhistory = false org.eclipse.debug.ui/debug/viewers/stateSaveRestore = true org.eclipse.debug.ui/debug/viewers/presentationId = org.eclipse.debug.ui.DebugView org.eclipse.debug.ui/debug/breadcrumb = false org.eclipse.cdt.dsf.ui/debug = true org.eclipse.cdt.dsf.ui/debug/vm/contentProvider = true org.eclipse.cdt.dsf.ui/debug/vm/delta = true org.eclipse.cdt.dsf.ui/debug/vm/cache = false org.eclipse.cdt.dsf.ui/debug/vm/presentationId = org.eclipse.debug.ui.DebugView org.eclipse.cdt.dsf.ui/debug/vm/atomicUpdate = false org.eclipse.cdt.dsf.ui/debug/stepping = true org.eclipse.cdt.dsf.ui/debug/disassembly = false
Unfortunately, I cannot create a reproducible case based on PDA sample. Note that following trace is emitted when the off-screen thread is selected. I do not see anything unexpected: updateElement(Block (0,0,0), 8) > modelIndex = 8 updateNodeChildren(node = ThreadsVM, update = VMChildrenUpdate:Block (0,0,0) {8->9}) replace(Block (0,0,0), modelIndex: 8 viewIndex: 8, Thread (8,0,0)) updateHasChildren(Thread (8,0,0) setHasChildren(Thread (8,0,0) >> false I will update this bug when I have reproducible case based on PDA example.
