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

[Klaus Weide]

On Mon, 19 Apr 1999, Leonid Pauzner wrote:
> 18-Apr-99 01:24 Leonid Pauzner wrote:
> > 29-Mar-99 16:50 Bela Lubkin wrote:
> >> This fixes one of the reported problems (characters other than INTERRUPT
> >> causing the DNS lookup delay to be shortened).  It also fixes a serious
> >> problem that I noticed while looking into the other reports: if fork()
> >> failed, we were blindly going ahead and doing who knows what, including
> >> kill(-1, SIGTERM)!  On my system, that means "send SIGTERM to every
> >> process with my UID" -- bad news indeed.
> 
> >> But I don't think that's what Leonid was running into.  That's something
> >> else, possibly the need to signal((various signals), quench) *before*
> >> fork().
> 
> >> CHANGES:
> 
> >>   * Behave sanely if NSL_FORK fork() fails. -BL
> >>   * NSL_FORK try for dns_patience *seconds*, not dns_patience select()
> >>     calls, which might have been shortened by keyboard input. -BL
> >>   * Fix some screwy comment indentation.
> 
> > 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.

Did you interrupt with 'z' at any point?  When?

Anyway, in your trace both lookups succeded:

> LYGetHostByName: NSL_FORK child 2379 exited, status 0x0.
> End of LYGetHostByName: 0x811c360 { h_name = 0x811c384 "lynx.browser.org",
>          h_aliases = 0x811c37c { 0x0 },
>          h_addrtype = 2, h_length = 4,
>          h_addr_list = 0x811c374 { 0x811c380 "195.40.122.44", 0x0 } }
> LYGetHostByName: Resolved name to a hostent.

> LYGetHostByName: NSL_FORK child 2380 exited, status 0x0.
> End of LYGetHostByName: 0x811c360 { h_name = 0x811c388 "bsd18.mccme.ru",
>          h_aliases = 0x811c37c {  0x811c397 "proxy.mccme.ru", 0x0 },
>          h_addrtype = 2, h_length = 4,
>          h_addr_list = 0x811c374 { 0x811c384 "195.133.68.18", 0x0 } }
> LYGetHostByName: Resolved name to a hostent.

Note the status 0x0 both times.  No problem here.

> > Exiting via interrupt: 15
> 
> 
> > [1]+  Stopped                 lynx
> > address@hidden pauzner]$ ps -a
> >   PID TTY STAT  TIME COMMAND
  .......
> >  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.?

 ------------------------

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

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

   Klaus