Community
Participate
Working Groups
I am seeing a problem with the pin and clone feature when cores/thread are grouped. Here is the scenario, pin Variables <1> view to threadA and Variables <2> view to threadB, than select the group and perform step/resume. The views should update when the threads are suspended, this is not the case at the moment.
Created attachment 192587 [details] patch for interface update I have simplified the interface a bit more, removed the eventType parameter and added the newSelection parameter. Since we only need to blank the view or update the view with the new selection, it doesn't really need to have the eventType. If the selection parameter is null, than blank the view, otherwise pass the selection to the view.
I am trying to work on the gdb-dsf case to refresh the view but not sure whether this is the right thing to do. When a pinned thread is suspended, I need to expand the thread and select the first stackframe to update the pinned view. However, the selection will be filtered by the SelectionPolicy and will not cause other non-pinned view to update. Is this the right thing to do? Also, I have a multi-threaded program, when a process is suspended, only the first thread is expanded. Is there any issue to expand the other suspended threads?
(In reply to comment #1) > Created attachment 192587 [details] > patch for interface update > > I have simplified the interface a bit more, removed the eventType parameter and > added the newSelection parameter. Since we only need to blank the view or > update the view with the new selection, it doesn't really need to have the > eventType. If the selection parameter is null, than blank the view, otherwise > pass the selection to the view. I like this version. It is simpler and seems somewhat more future-proof by allowing to send in the new selection.
(In reply to comment #2) > I am trying to work on the gdb-dsf case to refresh the view but not sure > whether this is the right thing to do. When a pinned thread is suspended, I > need to expand the thread and select the first stackframe to update the pinned > view. However, the selection will be filtered by the SelectionPolicy and will > not cause other non-pinned view to update. > > Is this the right thing to do? > > Also, I have a multi-threaded program, when a process is suspended, only the > first thread is expanded. Is there any issue to expand the other suspended > threads? I don't think the pin&clone feature should modify the debug view expansion state. Is there no other way to create a selection without actually causing the selection in the debug view? Can't we create a selection ourselves using the debug context we want it to contain?
(In reply to comment #4) > I don't think the pin&clone feature should modify the debug view expansion > state. > Is there no other way to create a selection without actually causing the > selection in the debug view? Can't we create a selection ourselves using the > debug context we want it to contain? Dobrin and I don't really like this solution either. The debug view is lazy, inorder to retives the DMVMContext and the tree path to construct the selection, the node has to be expanded. Is there a way for gdb-dsf to returns the stackframe DMVMContext and it's tree path without expanding it? If there is a way, than we can create the selection ourselves.
(In reply to comment #5) > (In reply to comment #4) > > I don't think the pin&clone feature should modify the debug view expansion > > state. > > Is there no other way to create a selection without actually causing the > > selection in the debug view? Can't we create a selection ourselves using the > > debug context we want it to contain? > > Dobrin and I don't really like this solution either. The debug view is lazy, > inorder to retives the DMVMContext and the tree path to construct the > selection, the node has to be expanded. Is there a way for gdb-dsf to returns > the stackframe DMVMContext and it's tree path without expanding it? If there is > a way, than we can create the selection ourselves. I don't know myself. Maybe asking the list would prove more useful :-) Can you explain why stepping a group changes the pin context? I would think it would be the grouping operation that would cause trouble right away, no?
(In reply to comment #6) > I don't know myself. Maybe asking the list would prove more useful :-) > Can you explain why stepping a group changes the pin context? I would think > it would be the grouping operation that would cause trouble right away, no? Stepping does not really change the pin context. When we resume, the view is blank out, we need to update the view again when the stack is fully constructed. Groupping does not blank out the view. Also, the pin context is remembered based on the session-process-threadId. Give this a try, pin an ungroup thread and than group it.
(In reply to comment #6) > I don't know myself. Maybe asking the list would prove more useful :-) There are two things that I don't know: 1. Why other threads are not expanded for gdb when I suspend the process? How come only the first thread? 2. How to retrives DMVMContext and node path without expanding the tree. I guess you are referring to #2. Do you know the answer for #1?
I have commit the "patch for interface update" path to HEAD.
(In reply to comment #8) > (In reply to comment #6) > > I don't know myself. Maybe asking the list would prove more useful :-) > > There are two things that I don't know: > > 1. Why other threads are not expanded for gdb when I suspend the process? How > come only the first thread? I think this is by design. I can't find where this happens in the *VMNode classes though. This was all done by Pawel and Toni I believe.
(In reply to comment #7) > (In reply to comment #6) > > I don't know myself. Maybe asking the list would prove more useful :-) > > Can you explain why stepping a group changes the pin context? I would think > > it would be the grouping operation that would cause trouble right away, no? > > Stepping does not really change the pin context. When we resume, the view is > blank out, we need to update the view again when the stack is fully > constructed. But the selection is the same as before, so that should work. > Groupping does not blank out the view. Also, the pin context is remembered > based on the session-process-threadId. Give this a try, pin an ungroup thread > and than group it. Right, once you group, the context hierarchy changes and will need to be changed in the pinned view. Can't we construct the new selection based on the old selection and the new DMC hierarchy?
(In reply to comment #10) > I think this is by design. I can't find where this happens in the *VMNode > classes though. This was all done by Pawel and Toni I believe. Check the StackFramesVMNode#buildDelta line 649. How come only one threadDmc is return? Where I have an app that has multiple threads and they all suspended. (In reply to comment #11) > Right, once you group, the context hierarchy changes and will need to be > changed in the pinned view. Can't we construct the new selection based on the > old selection and the new DMC hierarchy? We don't really need the DMVMContext once the view is pinned, only the thread id is required. To recreate the selection from the old selection makes me worry, because what happend when I call to the old DMVMContext to retrive thread name, process, etc? Also, what do we do with the path in the selection? The object might have a different path if it is groupped. Not sure if a view will make use of the path from the selection at this point.
