Bug#35049: The bash segfault problem

[Richard Braakman <dark@xs4all.nl>]

Package: libc6
Version: 2.1.1-0.1

I have some preliminary results for this. 

The symptom: A bash compiled on a slink system will always segfault
immediately when run on a potato system.  This interferes with upgrades.

Cause of the segfault: bash tries to call stat, which is not resolved
by fixup.  It ends up trying to call a function at address 0.

The symbol "stat" is defined by the libreadline in slink, so a bash
compiled against that libreadline will try to use it.  The symbol
"stat" is _not_ defined by the libreadline in potato.  It is not
defined by any other library either.  So bash crashes.  I don't know
why this doesn't cause a pretty linker error message.

"stat" is normally not defined as a symbol, because <sys/stat.h> defines
an inline function for it that wraps __xstat.

I'm not exactly sure where it comes from in libreadline.  It's not
part of any of its .o files.  It also has no debug information, even
though libreadline is compiled with -g.  It's definitely the wrapper
for __xstat that is defined in <sys/stat.h>.  It's definitely in the
text section of libreadline.so, though it's not in libreadline.a.

My best guess is that something caused gcc to include a standalone
version in addition to inlining it, despite the "extern __inline__"
combination.

When I compile potato's bash (2.02.1-1.3) on a slink system, its
libreadline still has a "stat" symbol, but its bash executable does
not refer to this symbol.  When I compile slink's bash (2.01.1-4.1) on
a slink system, its bash executable does refer to this symbol.  I have
been unable to find the reason for this difference.

Note that all these comments apply to fstat and lstat too, it's just
that bash happens to crash on stat first.

A scan shows that quite a few binaries define a "stat" symbol in
their text section.

It does not matter for bash whether I compile on a slink system or a
potato system, but it does matter for libreadline.  If I compile
2.02.1 on a potato system, its libreadline will not define the stat
symbol.

Oh... once thing I noticed just now is that bash 2.02.1 compiles
with -D_FILE_OFFSET_BITS=64 when compiled on a potato system.
That may be it.  It means that both libreadline and bash will
use stat64 rather than stat.  Indeed, this is what makes potato's
libreadline fail to define stat -- it does define stat64 instead.
The bash that goes with it is still well-behaved and refers only to
__xstat64.

I hope this makes sense.  I'm too tired to continue now.  The easiest
solution may be to force libreadline to include a definition of stat,
by taking its address or something.

Richard Braakman