This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strange freezes when using gdb (rxvt/mintty but not dos box)

Hi Corinna, Dave and Christopher...

First thanks all for your replies.... wrote on 20.02.2009 19:05:15:
> On Feb 20 12:45, Christopher Faylor wrote:
> > On Fri, Feb 20, 2009 at 06:26:17PM +0100, Corinna Vinschen wrote:
> > >On Feb 20 12:13, Christopher Faylor wrote:
> > >> On Fri, Feb 20, 2009 at 04:45:00PM +0000, Dave Korn wrote:
> > >> >Roland Schwingel wrote:
> > >> >>gdb freezes upon execution of the inferior process when used from
> > >> >>within mintty/rxvt, but does not freeze when gdb is invoked from a
> > >> >>(conventional) bash inside of a windows DOS box.
> > >> >[...]
> > >> >>But why does it work with DOS box and not using mintty/rxvt???
> > >> >
> > >> >Clue here. You are launching a win32 app, from a cygwin app, in a
> > >> >(non-console-based) GUI window. Won't work. Use a console. See
> > >> >discussions around CYGWIN=tty for full details (which, if you had it
> > >> >set, ought to make the crash occur in a console as well as in
> > >> >rxvt/mintty, but isn't anything you can turn off for rxvt and get it
> > >> >working).
> > >>
> > >> Right on, Dave. There are all sorts of potential problems with using
> > >> a cygwin pty/tty and a mingw process.
> > >>
> > >> So: what he said.
> > >
> > >What about the new-console option in Cygwin's GDB to create the inferior
> > >process in a new Console window? Shouldn't that help here, as long as
> > >the pty is actually running in the local GUI session.
> >
> > I don't think that resets stdin/stdout for the inferior process so I
> > doubt that it would help.
> Indeed, that could be a problem. I was just wondering if this win32
> app doesn't actually opens the console by itself and uses functions
> like WriteConsole. That could explain why it hangs.

Your assumption that the differences between cywin and native app are the reasons for the hang are true.
I turned my little test app into a native cygwin app by using pthreads and I got no hang when debugging it.

While this is a solution for this little test app it is not a solution for me in real life. I can't turn my native apps
into cygwin apps. For many years I use cygwin gdb to debug native apps. So I started to dig a little deeper...

gdb starting from 6.8 introduced this new feature of printing thread events. When I switch them off using
"set print thread-events off" inside of gdb before starting my native app it works without block.. Hmmm...
gdb uses its internal function printf_unfiltered() to print the tread events (eg. "[New thread 2060.0xca4]").
This function is used all over gdb for printing things. So the problem of gdb hangings can reappear for
me at any time if gdb wants to print something while a thread in the inferior process also prints.
(BTW: When I kill the native process when cygwin gdb started to hang gdb awakes again and is fully
functional). When analyzing gdb I found that the print is sent (after some hops) to cygwin's stdout
(what a surprise... ;-)).
Here I am running out of knowledge now how cygwin handles stdout once for itself and once for native
applications. Well... I made some more tests. If I force GDB/native application to always run on just one
CPU core I never got any hang. I tried it a lot of times without a problem. There is IMHO a solution possible
when it would be possible to serialize native and cygwin output so that they do not interfere. I do not
know whether this is possible to do or not.

Thanks again for your help,


-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]