lynx-dev
[Top][All Lists]
Advanced

[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]