Re: [schwidefsky@de.ibm.com] libc/1447: malloc fails if the executable is called via /lib/ld-2.1.1.so ./testexec

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   From: Ulrich Drepper <drepper@cygnus.com>
   Date: 14 Nov 1999 10:39:34 -0800

   Andreas Jaeger <aj@suse.de> writes:

   > We received the appended bug report about a different behaviour of
   > malloc when a program is called via /lib/ld-linux.so.2.  On my systems
   > I got:
   > aj@arthur: 19:26:27 /tmp 
   > $ ./ld-malloc 
   > Malloc returned 8049790
   > 
   > aj@arthur: 19:26:29 /tmp 
   > $ /lib/ld-linux.so.2 ./ld-malloc 
   > Malloc returned 80014198
   > 
   > (compare the values - for Martin (?) Schwidefsky the second call
   > failed completly - on my system (2.1.2 plus a number of patches) it's
   > just a different value.
   > 
   > Is this a bug in the current sources?

   This has nothing to do with the libc.  It's just how ther kernel
   works.  It starts the heap right after the data section of the
   program.  If the program is a pure executable it has a fixed load
   address.  This is the normal case.  In case you run a dynamic object
   the load address is a different and the heap ends up in a different
   position and in this position there might be other objects blocking
   the extension of the heap.  Not much one can do if the kernel decides
   to do it this way.

The Linux kernel tries to load dynamic objects at a sensible location
to avoid this problem, but apparently this is broken in Linux 2.2.10.
The algorithm for choosing the location was changed in 2.2.11, and as
Andreas and I can confirm, this seems to be working.

I suspect that the same kernel bug is responsable for the various
"segmentation fault in sunrpc directory" reports (for example PR
1448).  Maybe we should prevent people from trying to build glibc on
2.2.x kernels with x <= 10.

Mark