[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Re: 2.8.5dev.7 crash on Cygwin

From: Thomas Dickey
Subject: Re: lynx-dev Re: 2.8.5dev.7 crash on Cygwin
Date: Sat, 21 Sep 2002 11:55:54 -0400
User-agent: Mutt/1.3.27i

On Sat, Sep 21, 2002 at 05:09:40PM +0200, Clemens Fischer wrote:
> Thomas Dickey <address@hidden> writes:
> >
> >
> > (for isolating it, both gdb and strace were worthless - the bug would go 
> > away
> > when using those tools ;-)
> i admire your abilities to analyse this wide variety of bugs on so
> many different platforms, but i've just got to know:  how did gdb and
> strace make the bugs disappear?

The bugs simply didn't happen when I ran those tools.  I don't know why - when
I got the stack dump, I tried first using gdb, and saw no problem.  So I went
off to google to see if there were any clues there - noticed a comment about
strace (which I hadn't noticed was on cygwin), and tried that - same result.

No one seems to have a good way to analyze the stack dumps, so I turned on
lynx's trace to get some clues - and saw the trace file was not long. 
Apparently something broke in initialization.  I assumed it had something to do
with ncurses, so I checked one of the test programs there and got the same sort
of behavior.  ncurses has more traces, and I added a few more to pinpoint that
it was breaking the first time ncurses tried to fflush(stdout).  But the
runtime said that stdout was open, no errors on it.  Guessing that there was
some permissions problem with the parent process still owning the stream to
/dev/tty, I tried reopening it - and that made it work.

So I'm guessing that gdb and strace (probably don't open /dev/tty), were
tweaked to make them work in that sort of combination.  It's not by reopening
/dev/tty (since strace doesn't do that).

Thomas E. Dickey <address@hidden>

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]