Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 51880

Summary: CDT debugger fails to suspend target
Product: [Tools] CDT Reporter: Cameron Stevens <cameron.stevens>
Component: cdt-debug-cdi-gdbAssignee: Alex Chapiro <achapiro>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: alain, cebarne2, nobody
Version: 1.2   
Target Milestone: 2.1   
Hardware: PC   
OS: Windows 2000   
Whiteboard:

Description Cameron Stevens CLA 2004-02-12 14:02:47 EST
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.
Comment 1 Alain Magloire CLA 2004-02-16 15:26:41 EST
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.
Comment 2 Cameron Stevens CLA 2004-02-17 12:53:00 EST
gdb displays similar behavior in stand-alone mode.  That is, CTRL+C does not 
cause the target to suspend.
Comment 3 Alain Magloire CLA 2004-02-17 13:16:43 EST
> 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-)
Comment 4 Cameron Stevens CLA 2004-02-17 13:55:23 EST
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.


Comment 5 Alain Magloire CLA 2004-02-18 17:49:16 EST
> 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.
Comment 6 Kleo Hapitas CLA 2004-07-07 16:54:51 EDT
PR was not targeted to any particular release. Changing target milestone to 2.1
Comment 7 Doug Schaefer CLA 2004-11-17 18:40:20 EST
Hi Alex, you own this and it hasn't been touched since February. Any resolution?
Thanks.
Comment 8 Alain Magloire CLA 2004-11-17 18:59:36 EST
It was fixed.

Cameron please reopen if it still happens
or turn to verified if you agree it was fix.