Bug#: 415 -- binutils segmentation fault (chroot)

Greg Schafer 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
> others.
> 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
affect everybody.

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
   his own
 * there were substantial changes to the bash malloc in between 2.05a and
   2.05b
 * 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.

Greg
-- 
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 mailing list