[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LYNX-DEV Problems with lynx2.7.1ac-0.101 (in general and specifically on
From: |
WWW server manager |
Subject: |
LYNX-DEV Problems with lynx2.7.1ac-0.101 (in general and specifically on LINUX) |
Date: |
Thu, 18 Dec 1997 14:54:38 +0000 (GMT) |
I just noticed that lynx 2.8 was imminent, and that reminded me of a problem
I'd noticed on LINUX with an earlier (Foteos Macrides) 2.7.1 update (except
that unfortunately I got sidetracked by other work before getting as far as
a bug report - sorry!). That problem doesn't seem to have been fixed, so
presumably no-one else noticed it. I've also noticed a couple of other (new)
problems, which I'll deal with first.
(1) LYBookmark.c gives a syntax error at line 603 (with both Sun's C
compiler on Solaris 2.6 and gcc on LINUX). At a quick glance, the problem
appears to be an extraneous "}" on the previous line - commenting that out
certainly allows it to compile though I haven't looked closely enough to be
sure it's the right fix.
(2) While arguably "my fault", the configure script got confused on LINUX
(not Solaris 2, for some reason) by (a) having the shell variable "nolobber"
set (rejecting attempts to redirect output to an existing file) and (b)
having cd defined (when interactive) as a shell function which does a pwd
after changing directory. I've not hit that problem before with any other
configure scripts, and it took quite a while to track down the cause - it
nearly got a "this configure script is broken" bug report. :-(
The "noclobber" one was fairly obvious from the error messages, but the cd
shell function simply caused configure to complain (wrongly) that "make"
didn't support include files. I mention it only so people will be aware of
the potential problems and maybe avoid wasting time tracking down the cause,
unless it's felt to be worth fixing configure to avoid being sabotaged in
those ways.
(3) The more serious problem: lynx' replugging of stderr file descriptors
appears to be seriously misguided, and breaks on LINUX systems (seen with Red
Hat 4.something - I can check if relevant, I'm not responsible for the OS
and it doesn't identify the specific version anywhere obvious).
The problem originally noticed was that "lynx -help |more" resulted in the
output stopping prematurely, half-way through, though it was complete if
not piped into more, but that seems to be the tip of the iceberg.
I haven't had a chance to repeat the investigation with the lynx 2.8
pre-release, other than confirming that the above problem is still there and
the underlying cause appears the same, but from when I looked at Foteos
Macrides' version a while ago, the cause seemed to be the way in which FILE
structures (not e.g. addresses of FILE structures) for stderr are shuffled
to cope with redirecting trace output. The help output is to stdout, not
stderr, but the fudging used to shuffle stderr seems to break it.
I thought that maybe the output was not getting flushed properly because of
the way the structures were being swapped, so I tried various possibilities
with fflush(stdout) and fflush(NULL) before and after stderr is swapped in
LYexit.c, with widely varying but unhelpful results ranging from lynx
crashing to it going into a CPU-bound loop, depending in part on whether I'd
used tracing and/or whether I'd used "!" to run a subsidary process.
A colleague with more experience of LINUX internals immediately came up with
an explanation for this odd behaviour (when the same code works fine on
Solaris 2).
Whereas older UNIX flavours (e.g. Solaris 2) simply have a static array of
self-contained FILE structures, so that replacing one (i.e. the whole
structure) with another works as long as you ensure they are all eventually
flushed and tidied up cleanly, LINUX apparently uses a linked list of FIL
structures. In the LINUX stdio.h, there is
#define stderr _IO_stderr
which is defined in libio.h as
#define _IO_stderr ((_IO_FILE*)(&_IO_stderr_))
and _IO_FILE is defined as a substantial structure (containing much more
detail than the simple Solaris 2 version) including the linked-list
pointer to the next FILE in the list.
It's hardly surprising that overwriting an entry in the middle of a linked
list will have bizarre and variable consequences, including potentially
taking a flying leap into nowhere using a link pointer that is not currently
valid and going into a tight loop if (for example) you reinstate a linked
list entry which has a pointer back to a structure that is now earlier in
the list. And the effect will depend on what has been done with both the
structures that are being shuffled and others in the linked list.
What seems to fix it, but for no particularly good reason (the whole
stderr-shuffling strategy seems fundamentally flawed) is to fflush(stdout)
immediately before
*stderr = LYOrigStderr;
#endif /* !VMS */
exit(status);
It may be pure luck that works for me, since it's relying on the way things
just happen to work after the file-handling setup has been fairly thoroughly
sabotaged; fflush(NULL) to flush all descriptors at that point was a
disaster, for example.
I hope someone can see how to fix it properly, though it looks as if the
current way of shuffling stderr arose as the only workable solution (for
some operating systems :-) to problems encountered with an earlier approach.
John line
--
University of Cambridge WWW manager account (usually John Line)
Send general WWW-related enquiries to address@hidden
- LYNX-DEV Problems with lynx2.7.1ac-0.101 (in general and specifically on LINUX),
WWW server manager <=