Red Hat Bugzilla – Bug 634660
"heap" command sometimes not available
Last modified: 2010-10-05 09:15:39 EDT
Description of problem:
I tried attaching to gedit, but "heap" was not available; the hooks were not autoloaded
"Reading symbols from /lib64/libc.so.6...Reading symbols from /usr/lib/debug/lib64/libc-2.12.90.so.debug...done."
whereas my hooks are in: /usr/share/gdb/auto-load/lib64/ld-2.12.90.so-gdb.py
do we need them in both? or to be moved?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
$ gdb attach $(pidof -x gedit)
Undefined command: "heap". Try "help".
Report on heap usage within gdb process
Seems to locate when invoked in this form:
libc.so.6 contains numerous malloc-related symbols:
$ eu-readelf -s /lib64/libc.so.6|grep malloc|wc -l
and contains "main_arena".
$ eu-readelf -s /lib64/libc.so.6|grep main_arena
1118: 00000032ccd8b180 2184 OBJECT LOCAL DEFAULT 34 main_arena
ld-2.12.90.so contains just two "malloc" functions, which are marked as "WEAK":
$ eu-readelf -s /lib64/ld-2.12.90.so|grep malloc
23: 00000032cc615fe0 13 FUNC WEAK DEFAULT 11 malloc@@GLIBC_2.2.5
470: 00000032cc615fe0 13 FUNC WEAK DEFAULT 11 malloc
and does not contain "main_arena".
Looks like I should be autoloading the code based on whether libc.so is loaded, not ld.
I tried fixing this on a F14 x86_64 vm, but it didn't work.
I tried moving the hook for this code:
but in each case no autoloading occurred when attaching to a "gedit" process.
$ strace gdb attach $(pidof -x gedit) 2>&1 | grep gdb.py
shows very few files being autoloaded.
gdb folks: any ideas why:
$ gedit &
$ gdb attach $(pidof -x gedit)
wouldn't have gdb try to autoload -gdb.py files for the various DSOs making up the gedit process?
(reassigning to "gdb" for advice on the above; feel free to reassign back to "gdb-heap")
It works for spawned executables but not for attached executables.
gdbpy_global_auto_load is temporarily suppressed there.
[patch] python: load *-gdb.py for shlibs during attach
gdb-7.2-7.fc14 has been submitted as an update for Fedora 14.
I was using gdb-7.2-3.fc14.x86_64
Trying new gdb: gdb-7.2-7.fc14.x86_64
strace on the new gdb confirms that it's trying to load -gdb.py files for the
various dynamically-loaded DSOs. Thanks!
As it happens, the test case above now works, in that "ld" is linked into any
process using libc, so this happens to also fix the gdb-heap issue described in
In particular, it tried to load:
The last of these seems like the most appropriate place for my hooks.
But given that it's also loading relative to "ld.so", this works, without
needing to change gdb-heap.
Marking as VERIFIED.
gdb-7.2-7.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update gdb'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/gdb-7.2-7.fc14
gdb-7.2-12.fc14 has been submitted as an update for Fedora 14.
gdb-7.2-15.fc14 has been submitted as an update for Fedora 14.
gdb-7.2-16.fc14 has been submitted as an update for Fedora 14.
gdb-7.2-16.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.