Re: gdb/208: malloc'ed memory from GDB command line cannot be free'd from within program

[Michael Elizabeth Chastain <mec at shout dot net>]

The following reply was made to PR exp/208; it has been noted by GNATS.

From: Michael Elizabeth Chastain <mec@shout.net>
To: gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: gdb/208: malloc'ed memory from GDB command line cannot be free'd from within program
Date: Sat, 16 Aug 2003 19:19:13 -0400

 This bug is still happening.  Here is some analysis.
 
 The test program has two shared libraries:
 
   [mgnu@berman pr-208]$ ldd z2.exe
   libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
   /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
 
 It turns out that /lib/ld-linux.so.2 has a symbol 'malloc',
 which is a tiny implementation of malloc for its own use.
 
 gdb resolves the symbol 'malloc' from /lib/ld-linux.so.2
 instead of libc!
 
 The easy way to see this: 'print &malloc', and then look
 in /proc/$PID/map for that process, and notice that the address
 which gdb uses for 'malloc' belongs to /lib/ld-linux.so.2.
 Match this up with 'nm /lib/ld-linux.so.2'.
 
 This happens with:
 
   target=native, host=i686-pc-linux-gnu, osversion=red-hat-8.0
   gdb=HEAD 2003-08-16 19:47:28 UTC, gcc=3.3.1, binutils=2.13
   glibc=2.2.93-5-rh # this is where ld-linux.so.2 comes from
   gformat=dwarf-2, glevel=2
 
 So in the use case for the PR, the user calls the 'malloc'
 implementation in ld.so, and then the user's program calls
 the 'free' implementation in libc.  I don't see this actually
 crashing my 'free' but I see the mismatch.
 
 Here is another use case that fails:
 
   (gdb) break main
   (gdb) run
   (gdb) break malloc
   (gdb) cont
 
 gdb will break on the 'malloc' in ld.so which is generally not
 the 'malloc' that I want to debug.
 
 Obviously, linking with '-static' makes ld.so and its symbols go away,
 so that gdb does not get confused.
 
 The source for ld.so is in the glibc source, 'elf' directory.
 The ld.so malloc is in elf/dl-minimal.c.
 
 Lastly, the ld.so version of 'malloc' likes to return values within the
 data space of ld.so itself.  It knows that there is unused space at the
 end of the last data page and it returns that space.  (Note that the
 ld.so version of 'free' is a no-op).  That's why 'print p = malloc(10)'
 prints an address such as 0x400173a0, whereas libc malloc won't ever
 print an address like that.
 
 Michael C