Bugzilla – Full Text Bug Listing
| Summary: | [debug view][processes] There should be a preference to terminate debug session after the inferior process exits. | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Pawel Piech <pawel.1.piech> | ||||||
| Component: | cdt-debug-dsf-gdb | Assignee: | Marc Khouzam <marc.khouzam> | ||||||
| Status: | VERIFIED FIXED | QA Contact: | Marc Khouzam <marc.khouzam> | ||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | dd.general-inbox, elaskavaia.cdt, ling.5.wang, marc.khouzam, pawel.1.piech | ||||||
| Version: | 0 DD 1.0 | Flags: | marc.khouzam:
review?
(elaskavaia.cdt) |
||||||
| Target Milestone: | DD 1.1 | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Pawel Piech
(In reply to comment #0) Great idea! *** Bug 278823 has been marked as a duplicate of this bug. *** This has been annoying some people for some time. I wonder if it is too late in Galileo for me to add the preference and make the default to kill GDB in this case? You could change the default behavior for 6.0.1, and add the preference in 6.1? I think it should be off by default as in CDI, because how many people would want to interact with gdb when program terminates? It is easier to press debug again to create a new launch. I think it is worth fixing now even it is a ui change. (In reply to comment #5) > I think it should be off by default as in CDI, because how many people would > want to interact with gdb when program terminates? Cannot agree more ! Actually I strongly oppose adding that UI option as I think it offer little (if any) value but contaminate the UI. We should always balance off between feature and usability/simplicity of UI. And that option is, IMHO, an extremely "advanced" feature that can easily be got from command line if any one really wants it. Anyway, I like changing the default behavior. (In reply to comment #6) > Actually I strongly oppose adding that UI option as I think it offer little (if > any) value but contaminate the UI. We should always balance off between feature > and usability/simplicity of UI. And that option is, IMHO, an extremely > "advanced" feature that can easily be got from command line if any one really > wants it. The option would only in the global preference, so I don't think it would be complicating much. (I'm not saying we must have the preference, I'm just saying it will be pretty much out of the way.) How would you obtain this behavior from he command line? I think setting a breakpoint at the end of the program is the way to achieve this, no? (In reply to comment #7) > The option would only in the global preference, so I don't think it would be > complicating much. True. But it's occupying precious UI estate that can be used for more important things in the future. And the UI would eventually be messed up and become too scaring if we keep adding things that seems useful. Also whenever we add UI option, it incurs extra documentation and support work. > How would you obtain this behavior from he command line? > I think setting a breakpoint at the end of the program is the way to achieve > this, no? > The feature is to allow the user to interact with gdb after the debugged program finishes or is terminated, right ? I don't understand why some one would like to do that. If one really wants to do that, just play with gdb on command line. (In reply to comment #8) > (In reply to comment #7) > > The option would only in the global preference, so I don't think it would be > > complicating much. > True. But it's occupying precious UI estate that can be used for more important > things in the future. And the UI would eventually be messed up and become too > scaring if we keep adding things that seems useful. Also whenever we add UI > option, it incurs extra documentation and support work. You might be right. However, the change is coming really late in the release and I am affraid of breaking something. I'm willing to put in the change for 6.0, but there must be a way to turn it off just in case I missed a scenario. The preference gives me that 'safety net'. However, maybe there is a non-user-visible way to toggle this behaviour that I could use instead? A type of back-door? But I'm not sure that is the Eclipse way... > > How would you obtain this behavior from he command line? > > I think setting a breakpoint at the end of the program is the way to achieve > > this, no? > > > The feature is to allow the user to interact with gdb after the debugged > program finishes or is terminated, right ? I don't understand why some one > would like to do that. If one really wants to do that, just play with gdb on > command line. I don't have a specific scenario in mind but there may be some cases. For example, you debug in Eclipse and your program crashes; you had not enabled core files, so you don't have the core file; if gdb is still running, you can request that it dump a core file through the command line. I'm sure there are other example, although I'll agree it is a pretty advanced feature. Pawel, you were part of the original decision about this feature. Do you have an opinion about keeping it in a preference or hiding it in some non-user-visible way (if this is even possible)? Thanks (In reply to comment #10) > Pawel, you were part of the original decision about this feature. Do you have > an opinion about keeping it in a preference or hiding it in some > non-user-visible way (if this is even possible)? > > Thanks > I have no preference. (In reply to comment #9) > However, the change is coming really late in the release and I am affraid of > breaking something. I'm willing to put in the change for 6.0, but there must > be a way to turn it off just in case I missed a scenario. Then maybe we should change the default behavior in 6.0.1. > I don't have a specific scenario in mind but there may be some cases. For > example, you debug in Eclipse and your program crashes; you had not enabled > core files, so you don't have the core file; if gdb is still running, you can > request that it dump a core file through the command line. I'm sure there are > other example, although I'll agree it is a pretty advanced feature. > I understand whether to add the UI preference is a subjective matter. The only "fact" we have is that CDI debugger kills gdb on death of inferior and I've seen no bugzilla request for keeping gdb alive in that case. So following suit of CDI is a better choice. Created attachment 138293 [details]
Adding preference
This patch adds a global preference under Run/Debug->DSF->GDB.
The default of the preference is to terminate GDB when the inferior finishes, like CDI does.
There are minor UI changes and API changes.
Normally, I would not want to commit such a change so late in the process; however, I'm getting the impression that keeping GDB running may give the impression that DSF-GDB is not behaving properly and has bugs, which may dissuade some people from using it.
What do people think about committing this now vs 6.0.1?
Thanks for your input
(In reply to comment #13) > There are minor UI changes and API changes. > I'm wondering why you need to rename IGdbDebugPreferenceConstants to IGdbDebugConstants. Is it really needed aside from for shorter form ? (In reply to comment #14) > (In reply to comment #13) > > There are minor UI changes and API changes. > > > > I'm wondering why you need to rename IGdbDebugPreferenceConstants to > IGdbDebugConstants. Is it really needed aside from for shorter form ? It is because I had the limited vision of creating IGdbDebugPreferenceConstants in the UI plugin (dsf.gdb.ui) while now, I need to also check the preference in the non-UI plugin (dsf.ui). So the new file is created in the non-UI plugin. If there is a better way, I'd be very happy to use it. Any ideas? (In reply to comment #15) > It is because I had the limited vision of creating IGdbDebugPreferenceConstants > in the UI plugin (dsf.gdb.ui) while now, I need to also check the preference in > the non-UI plugin (dsf.ui). So the new file is created in the non-UI plugin. > Ok, I see. It makes perfect sense to move the class to engine plugin. But personally I prefer the old name with "Preference" in the middle as it makes it clear it's for preference and is shared by UI plugin. Just my 2 cents. (In reply to comment #16) > Ok, I see. It makes perfect sense to move the class to engine plugin. But > personally I prefer the old name with "Preference" in the middle as it makes it > clear it's for preference and is shared by UI plugin. Just my 2 cents. I imitated IDsfDebugUIConstants which is where the DSF preference constants are defined. But I can add preferences back in the name. Created attachment 138361 [details]
Final fix
After some testing I made a couple of modifications to the patch to avoid a potential race condition while processing the ContainerExitedDMEvent.
I'm committing the change. If we run into a problem, we can use the new preference to revert to the previous behavior.
Fixed. Elena, can you try it out? The new behavior (GDB being killed when the inferior terminates) should be enabled automatically. Ling, if you can give it a spin, that would be nice too. tested on linux ubuntu 8.04 with gdb 6.8 - Termination of gdb works as expected (terminates when process exists) - Preference found in Run/Debug->DSF->DBG - works as expected I tested local linux debug, our own local and remote debug, the termination works as desired. As I'm still using a local copy of old DSF 1.x code in our project, I didn't bother back porting the UI part. (In reply to comment #22) > I tested local linux debug, our own local and remote debug, the termination > works as desired. Thanks! |