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

[Klaus Weide]

On Mon, 29 Mar 1999, Leonid Pauzner wrote:

> >> 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
>[...]
 
> 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.

I don't understand what you mean with 'too far consequence'.

> The latter may be a problem when that document not cached

Were you going back in history, or following a link when you pressed 'z'?

> 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...)

I don't think it is a delayed effect at that level - If I understand you right,
Lynx already acted on the 'z', and (if you pressed 'z' only once), I don't
see how it can act on the 'z' again - it has already been eaten.
You seem to assume that "Alert!: Unable to connect to remote host." is from
the request you interrupted with 'z', and "Exiting via interrupt: 15" is
from the next request, right?  But I don't think that is the case; if it
were so, there should have been some intermediate status messages
("Getting ...", "Making HTTP connection to ...").

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

I don't understand.  Where and why?

  -----

I get the following, very similar to yours, by starting

     no_proxy='*' lynx -dump -tlog http://localhost -trace 2>&1|less

and then paging through the output with less rather quickly.  It is
repeatable.   I think I understand why the name lookup fails
(of course it normally always works for "localhost").  Each keyboard
input character shortens a select() in the NSL_FORK parent's loop,
even those that have been typed before the lookup started (and
enven though ther are not meant for lynx at all).  If there are enough
of those keys pressed (as compared to dns_patience=30), the patience
is exhausted before the child even has a chance to do a lookup for
localhost.  Maybe even before the child gets a chance to
execute signal(SIGTERM, quench), and that may be the reason why we
see the child's 'Exiting via interrupt: 15' at all.  The child is
killed by the parent's kill(fpid, SIGTERM) when the parent thinks
it's time to give up.   Output from parent and child are intermixed.

I still don't understand it completely.  And don't know exactly how this
relates to your case.   Did you press many (at that time dead) other
keys before or after the 'z'?


--------------- output ---------------
[.......]
New anchor 0x81a8c38 has hash 95 and address `http://localhost/'
HTAccess: loading document http://localhost/
HTParse: aName:http://localhost/   relatedName:file:
HTParse: result:http
HTParse: aName:http://localhost/   relatedName:
HTParse: result:localhost
Looking up localhost.
HTParseInet: parsing `localhost'.
HTParseInet: Can't find internet node name `localhost'.
Unable to locate remote host localhost.
HTTP: Unable to connect to remote host for `http://localhost/' (errno = 10).

Alert!: Unable to connect to remote host.



Exiting via interrupt: 15

HTAccess:  status=-29999
HTAccess: `http://localhost/' has been accessed, No data loaded.

lynx: Can't access startfile http://localhost/
LYStoreCookies: save cookies to /home/lynxdev/.lynx_cookies on exit
LYStoreCookies: 922715707 cf 2145801600 STORED
--------------- end ---------------
[ more LYStoreCookies, that's all ]