[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: strange HTTP/HTCheckForInterrupt() bug lynx-dev
From: |
Leonid Pauzner |
Subject: |
Re: strange HTTP/HTCheckForInterrupt() bug lynx-dev |
Date: |
Mon, 19 Apr 1999 19:41:03 +0400 (MSD) |
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