Bug#: 415 -- binutils segmentation fault (chroot)
gschafer at zip.com.au
Thu Sep 26 17:41:54 PDT 2002
On Thu, Sep 26, 2002 at 07:17:45PM +0200, Tobias Roppelt wrote:
> This segfault happens when you do not install en_US locales with glibc but some
> Fix: export LANG, example: 'export LANG=de_DE'
> Maybe we should mention this in the book. I really tried hard to figure this
> out. ,-) Thought it was a problem with bash (using patched 2.05b), as it is
> said Grep in response to the bug-report, but it isn't.
If you're referring to me as "Grep" then I'm honored! I always wanted to be
named after a unix command line tool. In fact, some of my friends reckon I'm a
bit of a "tool" anyway :-)
But being serious for a moment, the fact that exporting LANG makes it work for
you is just a coincidence. It does not make it work for me.
This is one of those "doesn't affect everyone" type infuriating bugs. I have
watched this closely from the start. It affects some people in different ways.
It seems to be a memory corruption bug which probably explains why it doesn't
So far, I have seen reports of:-
* binutils configure failing (a plain segfault - the most common case)
* binutils configure failing (a plain segfault - but with added bonus of some
bash malloc diagnostic message)
* gcc configure failing (segfault)
* bash segfaulting on massive for loops
The most obvious thing to do is to put a "set -x" at the top of the binutils
configure script to see where it chokes. Well guess what? That makes it work!
This just confirms to me that it is weird memory corruption. I can reproduce
it with gcc-2.95.x and gcc-3.x so I don't think it is a compiler issue. Running
gdb on the core file produced by the segfault shows that it craps out somewhere
inside the bash malloc routines.
I'm not much of a programmer so what I say next may be bollocks:-
* bash uses its own memory allocation routines (bash malloc) rather than the
system supplied malloc (glibc)
* I assume this is because the system malloc is not fast enuff or somehow
inappropriate for use by bash hence why the bash author decided to write
* there were substantial changes to the bash malloc in between 2.05a and
* configuring bash with "--without-bash-malloc" makes it work
* it is possible that the bash malloc in 2.05b is fine, but it is somehow
exposing a bug somewhere else in the system
So in summary, if you experience segfaults using bash-2.05b, you can still
get it to work by fudging around the problem. For example, with the binutils
problem you can:-
sh -x ../binutils-2.13/configure --prefix=/usr --enable-shared
But to me, that is not acceptable. We need to find the real source of the
problem and fix it properly.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev