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

[Leonid Pauzner]

19-Apr-99 05:55 Klaus Weide wrote:
> On Mon, 19 Apr 1999, Leonid Pauzner wrote:
>> > Today I got the same strange buged behaviour, now with dev22.
>> > Perhaps I press "z" in a "bad" moment (during DNS search or a little 
>> > later).
>> > ^Z spawn me to a shell and "fg" return me back without visible problems.
>>
>>
>> Looking into trace log more carefully I found out that we use two DNS calls:
>> first to resolve anchor and the second for making TCP connection.

> Only if you don't give a complete URL, of course.

>> In case of local proxy we have the second DNS call for proxy address.
>> Probably, interrupting the first call we crash the second by some means?

> This is still a mystery to me.  It would help if the "Exiting with interrupt"
> message mentioned the process id.


>   .......
>> >  3203  p0 S    0:00 -bash
>> >  3215  p0 T    0:03 lynx
>> >  7156  p0 Z    0:00 (lynx <zombie>)
>> >  7261  p0 R    0:00 ps -a
>> > address@hidden pauzner]$

> This doesn't seem to have anything to do with the trace you showed,
> the pid of the zombie process is completely different.?

Sorry, this zimbie process info from the real crash,
and trace log was from a succesful resolve (I got crash very seldom
so I have no trace from that situation, sorry for confusion).

I was just surprised why
>> LYGetHostByName: Resolved name to a hostent.
message was 3 times - one for user-defined URL and *two* for proxy address.
Does there were two gethostbyname calls for proxy?
>  ------------------------

> Those traces are harder to understand because large sections
> are duplicated, both the child and parent write the same messages
> already buffered when the fork() occurs to the trace log.

> As I said in <http://www.flora.org/lynx-dev/html/month0399/msg00883.html>,
> try inserting a

>            CTRACE_FLUSH(tfp);
ok.

> before the second '#ifdef NSL_FORK' in LYGetHostByName().
> But I don't know that this has anything to do with the problem.

>    Klaus