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): gdb-heap-0.5-1.fc14.x86_64 How reproducible: 100% Steps to Reproduce: $ gedit& $ gdb attach $(pidof -x gedit) (gdb) heap Actual results: Undefined command: "heap". Try "help". Expected results: Report on heap usage within gdb process Additional info: Seems to locate when invoked in this form: $ gedit (gdb) run CtrlC (gdb) heap
libc.so.6 contains numerous malloc-related symbols: $ eu-readelf -s /lib64/libc.so.6|grep malloc|wc -l 50 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: /usr/share/gdb/auto-load/lib64/ld-2.12.90.so-gdb.py to: /usr/share/gdb/auto-load/lib64/libc.so.6-gdb.py and to /usr/share/gdb/auto-load/lib64/libc-2.19.90.so-gdb.py 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.
Upstream post: [patch] python: load *-gdb.py for shlibs during attach http://sourceware.org/ml/gdb-patches/2010-09/msg00365.html
gdb-7.2-7.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/gdb-7.2-7.fc14
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 comment #0. In particular, it tried to load: /usr/lib/debug/lib64/libc-2.12.90.so.debug-gdb.py /usr/lib/debug/usr/lib/debug/lib64/libc-2.12.90.so.debug-gdb.py /usr/share/gdb/auto-load/usr/lib/debug/lib64/libc-2.12.90.so.debug-gdb.py /lib64/libc-2.12.90.so-gdb.py /usr/lib/debug/lib64/libc-2.12.90.so-gdb.py /usr/share/gdb/auto-load/lib64/libc-2.12.90.so-gdb.py 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. https://admin.fedoraproject.org/updates/gdb-7.2-12.fc14
gdb-7.2-15.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/gdb-7.2-15.fc14
gdb-7.2-16.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/gdb-7.2-16.fc14
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.