[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev strange HTTP/HTCheckForInterrupt() bug
From: |
Klaus Weide |
Subject: |
Re: lynx-dev strange HTTP/HTCheckForInterrupt() bug |
Date: |
Mon, 29 Mar 1999 03:48:55 -0600 (CST) |
On Mon, 29 Mar 1999, Leonid Pauzner wrote:
> A strange bug found:
>
> When I activate a link (HTTP request sent; waiting for responce)
> one may get a delay due to a slow server or other problems
> so sometimes I 'z'ap it before receiving the actual data.
>
> Apperantly, *sometimes* lynx got aborted with exit status
> just after pressing 'z'. So I see
>
> Alert!: Unable to connect to remote host.
> Exiting via interrupt: 15
I have also seen this, or something very similar, but not often. I
thought that it must be a NSL_FORK child process, since the main
process still exists after this, and I had seen similar stuff earlier
(before some changes in HTTCP.c) when the NSL_FORK child would die
and try to do some cleanup that it should not do.
I don't really understand how the child process can exit via 15 (SIGTERM),
since it executes signal(SIGTERM, quench) at the beginning, and quench()
just does an _exit(), not an exit() which would really be LYexit()...
Does this also happen when you have TRACE off?
Try undefining DEBUG_HOSTENT_CHILD in HTTCP.c.
Also try inserting a
CTRACE_FLUSH(tfp);
before the second '#ifdef NSL_FORK' in LYGetHostByName().
But if you never used TRACE, this couldn't really have any effect.
I think.
> and at this moment Lynx hangs and something messed with a screen,
> so I press ^C and exit to the shell with
>
> Exiting via interrupt: 2
You might be able to recover from this with ^Z, possibly restoring tty
settings somehow, then fg.
> I cannot reproduce it cleanly but saw several times with dev20-dev~14.
> the system is Linux, lynx compiled with NSL-FORK. ncurses 1.9.9e
> No trace or debug info, sorry.
>
> As far as I can say, "Unable to connect to remote host." message
> come from HTTP.c and than something incorrectly closed after interruptiion.
Well, maybe it has nothing to do with NSL_FORK - now that I think more
of it, that seems more likely. But if it's not NSL_FORK, where would the
SIGTERM come from???
> Remember Klaus' recent fix for similar problem but haven't applied it yet.
At this point, I don't know whether it has anything to do with it.
It might even just hide the real problem.
> This may be a hint or probably unrelevant but the previous page
> we are trying to return to is a script generated page so prossibly not cached.
Klaus