LYNX-DEV NSL_FORK problem under gdb, and change

[Klaus Weide]

Some strange observations about the NSL_FORK code on one machine,
and a change made to the NSL_FORK code in 2.7.1ac-0.46:

I had compiled various Lynx binaries with -DNSL_FORK, with or without
-g, on solaris (sol.slcc.edu) with gcc.  I haven't noticed any problem
with them when I run them normally.  However, when I ran them under
the installed gdb debugger, even without without setting any
breakpoints, the first DNS lookup always failed.  The child process
fork()ed to do the actual gethostbyname() call would get a SIGTRAP
signal somewhere in a function called indirectly by gethostbyname(),
and dump core.  It doesn't seem to depend on the hostname argument.
 I don't know the cause of this, it probably is highly system
dependent, and/or depends on a specific version of gdb or the resolver
library.  I'm just wondering whether anybody else has seen this.

Anyway, as a result of this failure of the child process, the parent
process did execute the following: (see HTParseInet in HTTCP.c)

            IOCTL(pfd[0], FIONREAD, &cstat);
            if (cstat < 4)
                cstat = read(pfd[0], (void *)&sin->sin_addr , 4);

and blocked on the read.  The child would never send 4 bytes (it was
already dead), and there was no way to continue the lynx session.
(Because this only happend under gdb, I could still get to the (gdb)
prompt with ^C.)

It seems the above statement (do a blocking read if 4 bytes are not
yet available) is not useful - if the child finishes normally, it will
have done one write() of at least 4 bytes, so the ioctl() will set
cstat to >= 4.  If cstat==0, something unexpected has happend to the
child, and 4 bytes will never arrive.  Only if the ioctl(,FIONREAD,)
doesn't work as expected (i.e. does not set cstat to the number of
bytes available for reading) would the read(..,4) make sense; but if
this is the case for some platform, the code probably shouldn't be
compiled with -DNSL_FORK anyway.

I have changed the devel code to retry a gethostbyname() without
forking in the (cstat < 4) case, instead of the above.  This way I can
get lynx to run under gdb on sol, the second, third,... execution of
the forking lookup don't have any problems.  (I still get a nice core
file from the first time each session...)  Any reason why this is bad,
and/or why the previous code should be retained?


    Klaus

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;