Community
Participate
Working Groups
When changing the stack level in the debug view, a new IP is put in the editor. This IP is not removed when changing the stack level again. In fact, even stepping does not remove that IP.
I don't complete understand the issue. When changing the stack frames, old IPs are not typically erased (at least not in the standard debug model implementation). However when you step, all IP annotations associated with that thread or target should be erased.
(In reply to comment #1) > I don't complete understand the issue. When changing the stack frames, old IPs > are not typically erased (at least not in the standard debug model > implementation). However when you step, all IP annotations associated with > that thread or target should be erased. I finally had time to look at this again. Say you step into a method so as to have two stack levels. If you select the second level, an IP in inserted at the location represented by the stack frame. However, if you select the current stack frame again, the IP of the other stack frame is not removed. Further, if you do a step, the IP is still not removed.
(In reply to comment #1) > I don't complete understand the issue. When changing the stack frames, old IPs > are not typically erased (at least not in the standard debug model > implementation). Are they never erased when changing frames? The behavior I would expect is that the IPs of the selected frame as well as all stack frames above it should be seen; however, IPs for frames below the currently selected one should not be visible.
(In reply to comment #3) > Are they never erased when changing frames? ... This is correct. For better or worse this is the behavior that platform Debug first implemented with the standard debug model. This is the precedent, and probably the user expectation. However, the implementation is completely up to DSF and we can ignore this precedent if that seems more logical. BTW, I've always thought it was a bug that the IP is not shown for frames that were never selected, and that's something that I thought we could eventually address in DSF as well.
The part of the behavior where the IP is not cleaned up after step is fixed with bug 214389. But I don't remember what we decided about this bug in general. I.e. do we want to erase the IP as soon as the user selects another frame?
(In reply to comment #5) > The part of the behavior where the IP is not cleaned up after step is fixed > with bug 214389. But I don't remember what we decided about this bug in > general. I.e. do we want to erase the IP as soon as the user selects another > frame? Since the JDT does it like this (leaving the IP when changing stack frames, I agree to leave it as is. So, I'm marking as fixed because bug 214389 fixed the real issue.
Pawel, can you verify?
(In reply to comment #6) > (In reply to comment #5) > > The part of the behavior where the IP is not cleaned up after step is fixed > > with bug 214389. But I don't remember what we decided about this bug in > > general. I.e. do we want to erase the IP as soon as the user selects another > > frame? > > Since the JDT does it like this (leaving the IP when changing stack frames, I > agree to leave it as is. I was about to open a new bug for DSF, but after testing on the platform, I realized it was a platform issue. Or at least, I think it is an issue :-) The problem described by this bug seems to also cause the following: The IP of one launch remains in the editor even if another launch is selected. That means that if you launch two DSF debug sessions of the same binary, you will see the IPs of both launches in the source file. As I said, the same happens in the JDT. To me, that is not very nice. What do you think?
(In reply to comment #8) I think it's worth it to keep this defect open and have a wider discussion as far as what is our desired behavior with respect to erasing IPs when the corresponding frame looses focus.
I ran into this bug again and realized it does not only apply to stack levels. In a multi-thread application, if I select the stack frame of one thread, the code gets highlighted. When I change to another thread, a new IP is shown in the code, but the old one of the other thread is still showing. This seems to be true for any context. So we'll see this in multi-process as well. And we currently can see this with multiple launches. It is particularly bad if both threads (as an example) are running the same code, because it because multiple IPs can be within lines of each other. Furthermore, when stepping, the current IP is changed, but any old ones, remain. However, when stepping over a long operation, old IPs are removed.
I agree with you Marc. I will try to get this bug addressed along with bug 241075, although it is not scheduled right now.
Platform does not refresh mark-ups on debug context changed event. There's a long standing platform bug 49730
Created attachment 160022 [details] Removing all IPs in editor This patch mimics the platform solution of bug 49730 (which is also used by CDI). Whenever source will be displayed, all IPs are cleared from the editor. This allows to keep a single IP visible, based on the currently selected stack frame. I think it is better than what we have right now, but at a minimum, maybe this patch can get a discussion going to clarify how we want to solve this issue. This solution is only a start because it has the following problems (that I'm aware of): 1- does not deal with multiple DSF-GDB launches properly. This is because, unlike the platform, DSF's version of InstructionPointerManager is not a singleton. 2- does not deal with multiple launches of different kinds. Even if #1 was fixed, I don't think it would handle a CDI launch along with a DSF-GDB launch, again because they wouldn't be use the same InstructionPointerManager.
