This is the mail archive of the
libc-alpha@sourceware.cygnus.com
mailing list for the glibc project.
Re: [schwidefsky@de.ibm.com] libc/1447: malloc fails if the executable is called via /lib/ld-2.1.1.so ./testexec
- To: drepper at cygnus dot com
- Subject: Re: [schwidefsky@de.ibm.com] libc/1447: malloc fails if the executable is called via /lib/ld-2.1.1.so ./testexec
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Sun, 14 Nov 1999 21:40:26 +0100 (CET)
- CC: libc-alpha at sourceware dot cygnus dot com, schwidefsky at de dot ibm dot com
- References: <u8iu35gc4l.fsf@gromit.rhein-neckar.de> <m3iu34dijd.fsf@localhost.localnet>
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