Re: lynx-dev strange HTTP/HTCheckForInterrupt() bug

[Klaus Weide]

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