Mail Archives: cygwin/2009/02/23/08:37:31
Hi Corinna, Dave and Christopher...
First thanks all for your replies....
cygwin-owner AT cygwin DOT com 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,
Roland
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -