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

[Leonid Pauzner]

29-Mar-99 03:48 Klaus Weide wrote:
> 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?
The problem occur very seldom, maybe twice a week or so
so I never use TRACE since it fill lots of Megs easily.

> 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.
Will try next time.

>> 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, "Unable to connect to remote host" should be a too far consequence
since we interrupt the connection and trying to pop the previous document.
The latter may be a problem when that document not cached
and we can't process a new HTTP connection since
something was messed from our original interrupt
(may be a timing problem so a short delay is necessary between the processes
or something was not flash()'ed in some sence. So a new child
is not completely independent from a previous one...)

Oh, shouldn't we override "no_cache" for a poped document
in any case when the next HText_new() even not started?


> 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