Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] DSF: cannot pause a program

At 02:40 PM 7/6/2009, Doug Schaefer wrote:

On Mon, Jul 6, 2009 at 3:34 PM, Daniel Jacobowitz <drow@xxxxxxxxx> wrote:
On Fri, Jul 03, 2009 at 09:05:55AM -0400, Marc Khouzam wrote:
> I'm not very knowledgeable about signals so what I would do
> is set a breakpoint in CDT to see if we are trying to send
> the signal.

Signals... Oh, let me tell you about signals on Windows.  It doesn't
have any.  The closest thing is an interrupt event, which is
associated with a console.  I haven't looked at the source for CDT's
Spawner, but the odds are very good that it isn't creating a Windows
console for GDB; it's possible but infuriatingly hard to do this
without popping up a visible console window.

You can stop the debugged program using a debug break event.  You
have to either send it directly, or tell GDB to; if you somehow get a
CTRL_C_EVENT to the GDB process, it will do this for you.

If you use -exec-interrupt it will send a CTRL_C_EVENT to the
debuggee.  I don't know why this difference; you'd have to ask
on the GDB list and Chris Faylor can probably explain.

(Yes, I realize none of this explains how the previous CDT integration
handled it... sorry, I don't know, but this may be helpful anyway.

I scream in horror at the memories that are now mostly faded due to the shock of spending a few weeks trying to get this working on Windows.
Now from what I remember this is handled by using Windows Events to send a "signal" from the spawner.dll native to the starter.exe process which launches gdb. The starter does the CTRL_C_EVENT to itself to interrupt gdb. I think...

The horrors continue, btw :-) An engineer here recently found that in the case where the Java code sends the spawner a kill "signal" instead of the CTRL-C one, we can end up with in a tight loop in the spawner where it keeps sending a CTRL-C event to the spawned process. Turns out Windows creates a thread under the covers for each attempt. He saw some 7000 threads on his machine as a result. But fortunately, this seems like a coding mistake in the spawner logic. I'll be addressing it this week and will post something here since the fix, though a one-liner, might require some discussion.


Back to the top