Community
Participate
Working Groups
When launching a debug session using the "attach to process" option, the attach occurs successfully. I can set breakpoints at this time and resume. The breakpoints will be hit as expected and I can subsequently step, etc. However, if I don't set any breakpoints and simply resume the attached process immediately, and subsequently try to suspend execution, the suspend seems to time out (after 5 seconds), and I get an error dialog, "Suspend failed. Reason: Exceptions occurred attempting to suspend." The details indicate "Target request failed: Failed to interrupt." The only option this leaves me to be able to debug is to make sure I set/modify breakpoints in advance, or when a breakpoint is hit. This is obviously not the user experience I want. Of possible interest is that I am using the -mno-cygwin option and gcc 3.3.1 (cygming special) along with gdb 2003-09-20-cvs (cygwin-special) according to the information supplied from the --version option on the command line. The - mno-cygwin is a requirement for our project, and these particular versions of gcc/gdb were the most recent combination I could get working together.
The problem is that, you will have the same behaviour using command line gdb. If you CTRL-C it will not be suspended. Maybe we can try to bypass gdb and drop the signal ourself, I do not cygwin at hand to test but we'll give a try later this week. Meanwhile, when you are in gdb, attach and hit ctrl-c does is stop ? It may be an error on our part, I wan to confirm this.
gdb displays similar behavior in stand-alone mode. That is, CTRL+C does not cause the target to suspend.
> gdb displays similar behavior in stand-alone mode. That is, CTRL+C does not > cause the target to suspend. Then how do you manage, to suspend the application ? And we will try to "mimic" the scheme. You have to understand the underlying debugger backend __is__ gdb, if it fails, we will 8-)
Yup, I realize that we're at gdb's mercy here, and hence this may be beyond the control of CDT. On the other hand, this IS extremely relevent to CDT adoption, which is why I posted the bug here. I really want to see CDT succeed as a viable C++ development platform. I think its amazing how far its come already, and look forward to 2.0. However, if I can't perform a basic operation like setting breakpoints whenever I want, it becomes a non-starter, even if gdb is the underlying cause of the problem. Back to your question. The application suspends fine when I first attach to it, either in gdb or from Eclipse. Thus, any breakpoints I set IN ADVANCE, or set at the time it is first suspended, are capable of being hit later. I then resume the application. Once breakpoints are subsequently hit, I can once again modify/add/remove breakpoints. I haven't discovered a gdb mechanism to suspend the application while it is running, thus I don't have any suggestions for what techniques CDT could mimic. I'm happy to post a bug against gdb as well if this will help. However, I'm really not a gdb expert, haven't downloaded the source code, etc. This is another reason I posted the bug here. This issue relates to CDT adoption, so I felt you might have a vested interest in looking into it, and would probably be much better versed in gdb that I. On the other hand, I'm certainly not trying to unload my problems on you, so let me know if you wish me to pursue this directly with gdb.
> This issue relates to CDT adoption, so I > felt you might have a vested interest in looking into it, and would probably be > much better versed in gdb that I. Yes. Alex agreed to take a look at it. Since the process is attach we may find a way to suspend the debugger Redirected to Alex, for further look.
PR was not targeted to any particular release. Changing target milestone to 2.1
Hi Alex, you own this and it hasn't been touched since February. Any resolution? Thanks.
It was fixed. Cameron please reopen if it still happens or turn to verified if you agree it was fix.
