On Sun, 28 Sep 1997, Erik wrote:

> The following program will crash:
> 
> ======== example start ======
> /*
>  * $Source: /usr/distrib/1_2_beta/source/usr.bin/pr/RCS/hop.c,v $
>  *
>  * $Id: hop.c,v 1.5 1997/09/28 00:46:20 root Exp $
>  */
> 
> int err;
> 
> int
> main()
> {
> 	err = 123;
> 	return 0;
> }
> ======== example end ========
> 
> It simply declares a global variable called "err" and then assign a
> value to it. The way in which the value is assigned is irrelevant.
> The type of the variable is also irrelevant.
> 
> What is important is the name of the variable. If you change it to,
> for example, "beng", the program runs without problems.
> 
> I discovered this bug because the "pr" program crashes. Which is a
> pain any time you want to print something, as lpr uses pr to format
> the output. Debugging and examination of the source showed that the
> crash occured the moment a value was assigned to the global FILE
> *err. Lots of testing showed that it was the name of the variable
> which caused the problem.
> 
> If you are interested, I have modified the source of pr (pr.c) and
> recompiled it with GNU CC 2.7.2.1p1 to get a working version. Mail me
> for a copy.

Yep This is a know bug. It is a fault this the GNU linker we have been
using. If you have a variable name that matches with a library function
the symbols are combined. This means the libray function gets pulled in
the the address assigned to the variable name is the addess of the library
function. Thus when you try and assign something to it you end up trying
to write to the text area which is read only and thus get a SEGV.

The new shared library beta release does not have this problem as we no
longer use the GNU linker but use the NetBSD one instead.

Cheers,
				Mark