Re: sending CTRL-C to Cygwin gdb 6.8 has no effect

John Cortell
2010-04-25T14:10:29Z

At 07:15 PM 4/24/2010, Dave Korn wrote:
>On 24/04/2010 23:29, John Cortell wrote:
>
> > Great. That makes perfect sense now. So, given the behavior I'm seeing,
> > it would seem the gdb that CDT launches is NOT sharing the console with
> > the inferior. What is left for me to answer is "why?", since that's not
> > what I expect. CDT, through an intermediary launcher process, does a
> > Win32 CreateProcess call to launch gdb. The call specifies whether to
> > launch it attached or not, and if attached, whether to share the
> > console. Fine, but that is between CDT's launcher process and gdb, not
> > gdb and the inferior. The console relationship between gdb and the
> > inferior seems out of the hands of CDT. That is, once we establish an mi
> > connection with gdb, we till it to load aprogram.exe and run it. We
> > don't specify whether gdb should share the console with it. So what's
> > the expected behavior? Again, I would expect the two to share the
> > console. After all, they apparently do when I carry out the same thing
> > from a Windows command shell session. There too, I don't tell gdb to
> > share a console with the inferior or not, and apparently it does.
>
> What's probably getting in the way here is Cygwin's POSIX tty emulation,
>which has to interact with the Windows console in bizarre and sometimes
>unexpected ways. A Cygwin process launched from a standard Windows console -
>whether cmd.exe or bash doesn't matter - comes with its stdio handles attached
>to the console.
>
> However, a Cygwin process launched either from a shell running in
> one of the
>GUI consoles like xterm/rxvt, or if launched with CYGWIN=tty set in the
>environment, gets connected to a pty, which is implemented in windows terms as
>the ends of a pair of (iirc) named pipes. In that case, no console is created
>nor attached to the process, to avoid the "flashing black window" syndrome
>caused by a console appearing briefly even if you hide it.
>
> I haven't checked what the code in gdb exactly tries to do when it launches
>a process, but I'd infer from your observations that when the gdb itself is
>running attached to a console it launches the inferior sharing the console,
>and when not it may well let the new process create its own console.
>
> I quickly searched for "console" in the gdb info page, and discovered a
>couple of useful-sounding options:
>
> > `set new-console MODE'
> > If MODE is `on' the debuggee will be started in a new console on
> > next start. If MODE is `off'i, the debuggee will be started in
> > the same console as the debugger.
> >
> > `show new-console'
> > Displays whether a new console is used when the debuggee is
> > started.
> >
> > `set new-group MODE'
> > This boolean value controls whether the debuggee should start a
> > new group or stay in the same group as the debugger. This affects
> > the way the Windows OS handles `Ctrl-C'.
> >
> > `show new-group'
> > Displays current value of new-group boolean.
>
> Those sound like they ought to be of some use to you in this situation :)

Dave, that all got me pretty optimistic our problems would soon be
over :-). Unfortunately, none of it panned out.

1. I ruled out POSIX emulation in the inferior being a factor by
debugging a MinGW-built program. No change in behavior.CTRL-C to gdb
programatically has no effect.
2. I added 'set new-console off' in the .gdbinit file (and confirmed
it took effect with a 'show new-console' at debug time). No change in behavior.
3. I added 'set new-group on' in the .gdbinit file (and confirmed it
took effect with a 'show new-group' at debug time). The default is
on, btw. No change in behavior.

So, I decided to look at how we send the CTRL-C to gdb. If the
program spawned by our launcher is using the cygwin runtime dll, we
run a 'kill -SIGINT <PID>'. In this case, the launched program is
cygwin's gdb, which does use the cygwin runtime, so that's what we
end up doing. And for sure, this command isn't interrupting either
gdb or the inferior. So what I'll do tomorrow is see if we have more
luck using the Win32 call GenerateConsoleCtrlEvent(CTRL_C_EVENT ,
0)...that's what we use when the launched program is not using the
cygwin runtime.

Anyone know of a way to tell whether two running processes on Windows
are sharing a console...perhaps via some utility? Process Explorer
doesn't seem to reveal that information.

Again, I appreciate the insight.
John