Community
Participate
Working Groups
Build Identifier: 6.0.0.201002011403 Initial e-mail discussion on the topic: Alexiev, Dobrin wrote: Pawel, I followed your advice to have my container VM node return the top node - Container(1). In that case DefaultVMModelProxyStrategy.buildChildDeltasForEventContext() properly matches Container(1) with the returned from getVMProvider().updateNode() since they both are the top ones. But later in the next call of DefaultVMModelProxyStrategy.buildChildDeltasForEventContext() when the thread VM node is asked with getVMProvider().updateNode() it won’t return any nodes since there are no Thread children of Container(1). The threads are children of child container - Container(2) in my case - so the stack VM node won’t be asked for the delta. Without overriding my container VM node getContextForEvent() it returns the bottom one - Container(2) then DefaultVMModelProxyStrategy.buildChildDeltasForEventContext() cannot match that one against Container(1) - which is returned from getVMProvider().updateNode(). I agree that returning all containers in a getContextForEvent() won’t help either. Either way it doesn’t work… Do you want me to open a Bugzilla entry and we can transfer the discussion there? Yes, please. That'd be a good idea. -Pawel Thanks Dobrin -------------------------------------------------------------------------------- From: cdt-dev-bounces@eclipse.org [mailto:cdt-dev-bounces@eclipse.org] On Behalf Of Pawel Piech Sent: March 22, 2010 6:02 PM To: CDT General developers list. Subject: Re: [cdt-dev] Recursive DSF view model nodes in the debug view Alexiev, Dobrin wrote: Looking at the example (DSF Example - File Browser) I was trying to fit my use case, unfortunately unsuccessful so far. Here is my use case: The VM nodes hierarchy is setup as: LAUNCH - has child CONTAINER CONTAINER - has children CONTAINER and THREAD THREAD - has child STACK_FRAME When I have an instance: Launch(1) Container(1) Thread(1) Stack_Frame(1) the delta is generated properly and stepping selects the top stack frame. When I have an instance of recursive container: Launch(1) Container(1) Container(2) Thread(1) Stack_Frame(1) The debug view shows it properly, but the delta is not generated the way I was hoping. LaunchManager .NO_CHANGE Launch(1). NO_CHANGE Container(1).NO_CHANGE Container(2).NO_CHANGE I have my ContainerVMNode generate the delta in a similar way to FileVMNode.java - it includes all container nodes that are parents of the suspended thread. My ThreadVMNode adds the thread delta to the bottom container. At this moment I am not sure what should my ContanerVMNode.getContextsForEvent return? I think it should return the top container. Because your VM node is responsible for adding deltas for all the elements under the top container. Its default implementation return the bottom container - Container(2). But when that is passed to DefaultVMModelProxyStrategy.buildChildDeltasForEventContext() getVMProvider().updateNode(…) returns the immediate children of the Launch node - Container(1). When I change DefaultVMModelProxyStrategy.buildChildDeltasForEventContext() to return both containers I get one step ahead Did you mean you have "ContanerVMNode.getContextsForEvent()" return both contexts? I don't think that should work either. The delta now includes the thread: LaunchManager .NO_CHANGE Launch(1). NO_CHANGE Container(1).NO_CHANGE Container(2).NO_CHANGE Thread(1) NO_CHANGE But the stack frame is still not there. I can't tell without having a working model to debug with. I’ll keep debugging, but Before I continue on this I wanted to check if I am on the right track modifying ContanerVMNode.getContextsForEvent() to return the hierarchy of containers, or that is not the right approach and I am missing something else. You shouldn't have to return a hierarchy, because your node is reponsible for creating this hierarchy in buildDelta(). But I have to admit that you are doing something rather new here so you could be running up against limits of current implementation. So don't be afraid to experiemnt :-) Cheers,, Pawel Thanks in advance. Dobrin -------------------------------------------------------------------------------- From: cdt-dev-bounces@eclipse.org [mailto:cdt-dev-bounces@eclipse.org] On Behalf Of Pawel Piech Sent: March 19, 2010 5:19 PM To: CDT General developers list. Subject: Re: [cdt-dev] Recursive DSF view model nodes in the debug view Hi Dobrin, I'm sorry I haven't had time to look at this, could you create a bug with your patch so it doesn't get lost? Thanks! Pawel Alexiev, Dobrin wrote: Thanks Pawel for the pointers. I’ll follow them for my recursive container. BTW, I think the Windows version of FileVMNode.java needs slight adjustment to handle the multiple drives case. You can see if the attached patch makes sense. Without the patch pasting a path will expand all drives (root nodes) instead of one. May be there is a better fix than this patch? See how all drives are included in the delta when I paste “C:\Program Files\Adobe”. How can I make sure that only C drive is included in the delta? Thanks Dobrin RECEIVED DELTA: Model Delta Start Element: File Browser Viewer Input Flags: NO_CHANGE Index: 0 Child Count: 5 Element: C:\ Flags: NO_CHANGE Index: 0 Child Count: 85 Element: C:\Program Files Flags: NO_CHANGE Index: 58 Child Count: 92 Element: C:\Program Files\Adobe Flags: EXPAND | SELECT | Index: 0 Child Count: 5 Element: E:\ Flags: NO_CHANGE Index: 1 Child Count: 7 Element: M:\ Flags: NO_CHANGE Index: 2 Child Count: 1 Element: P:\ Flags: NO_CHANGE Index: 3 Child Count: 0 Element: Q:\ Flags: NO_CHANGE Index: 4 Child Count: 59 Model Delta End -------------------------------------------------------------------------------- From: cdt-dev-bounces@eclipse.org [mailto:cdt-dev-bounces@eclipse.org] On Behalf Of Pawel Piech Sent: March-04-10 7:26 PM To: CDT General developers list. Subject: Re: [cdt-dev] Recursive DSF view model nodes in the debug view Hi Bobrin, Alexiev, Dobrin wrote: Hello, Has anyone tried recursive view model hierarchy in the debug view using DSF? Yes, you can even look at org.eclipse.cdt.examples.dsf.filebrowser for an example ;-) It's a simplistic example though, so you may uncover new bugs in this area. I’d trying something like launch container thread stack frame(s) container container container container thread stack frame(s) container thread stack frame(s) It does show up properly in the debug view. But when I fire suspended event on the thread for some reason my StackFrameVMNode.buildDelta doesn’t get called even though its getDeltaFlags returns properly CONTENT + EXAPND + SELECT for ISuspendedDMEvent. I’ll keep digging into DefaultVMModelProxyStrategy code tomorrow. I just saw a comment “Avoid descending into recursive node hierarchy's when calculating the delta.” and decided to make sure I am not trying a use case that is not supported by design. What this means is that if you have a recursive hierarchy (i.e. a node that has itself as a child), then this node is responsible for building a delta with all the levels in this hierarchy. For example, in the hierarchy you have above when the container node is called, it needs to build a delta for all the nested containers before it completes so that the thread vm node can build on top of that. Hope this helps, Pawel In other words, when the ContainerVMNode.buildDelta() is called it needs to Thanks in advance! Dobrin -------------------------------------------------------------------------------- _______________________________________________ cdt-dev mailing list cdt-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cdt-dev -------------------------------------------------------------------------------- _______________________________________________ cdt-dev mailing list cdt-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cdt-dev -------------------------------------------------------------------------------- _______________________________________________ cdt-dev mailing list cdt-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cdt-dev -------------------------------------------------------------------------------- _______________________________________________ cdt-dev mailing list cdt-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/cdt-dev Reproducible: Always Steps to Reproduce: described in the e-mails thread in Details.
Is there any chance you could reproduce this problem with something that's in open source? E.g. extend the file browser example, or the PDA example to have nested containers? It's been a while since I looked at this code in detail, and it's hard for me to help without having a working example.
(In reply to comment #1) > Is there any chance you could reproduce this problem with something that's in > open source? E.g. extend the file browser example, or the PDA example to have > nested containers? It's been a while since I looked at this code in detail, > and it's hard for me to help without having a working example. I'll try later on today to extend the file browser example to show the issue. Thanks
Pawel, I modified the PDA example to include recursive VM node - PDAContainerVMNode. The example is very simplistic and hard coded but shows clearly the problem I am looking at. It works with a single threaded Perl program - I use 'fibonacci.pda'. The use case is simple: Once you start the debugging the Perl - manually collapse and select the Thread node and step. If everything works fine (the delta are generated correctly) the thread node will expand and the stack frame will get selected. I changed the code so there is a switch PDARunControl.variant so it is easy to switch between different cases: Case 0: the original code. Case 1: Adds a container VM between the virtual machine VM node and the thread node. Case 2: Makes the container VM node recursive but it still uses only one instance. Case 3: A recursive container VM node with two instances of PDAContainerVMNode - one child of the other. Only case 3 doesn't work as expected. While debugging you can set the switch inside the constructor of PDALaunchVMProvider. All my changes are marked with 'dobrin test'. Let me know if the provided info is sufficient for you to see the problem I am referring to. Thanks a lot for looking into this. Dobrin
Created attachment 162928 [details] pda.ui changes
Created attachment 162929 [details] pda.core changes
