[
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.
John
