Description of problem: Trying gdb-heap on thunderbird. gdb-heap is not seeing the memory allocations for thunderbird. Can run the thunderbird on valgrind massif tool and see that memory is definitely being allocated. Version-Release number of selected component (if applicable): thunderbird-3.1.6-1.fc14.x86_64 gdb-7.2-23.fc14.x86_64 gdb-heap-0.5-2.fc14.x86_64 How reproducible: every time Steps to Reproduce: 1. start up /usr/lib64/thunderbird-3.1/thunderbird-bin note the pid 2. PYTHONPATH=/usr/share/gdb-heap gdb 3. attach 1234 # fill in with appropriate pid number 4. heap # print out heap information Actual results: (gdb) heap Domain Kind Detail Count Allocated size ------ ---- ------ ----- -------------- TOTAL 0 0 Expected results: Show some memory allocated for thunderbird's use. Additional info: Valgrind's massif tool showed there was definitely memory being allocated: -------------------------------------------------------------------------------- Command: /usr/lib64/thunderbird-3.1/thunderbird-bin Massif arguments: (none) ms_print arguments: massif.out.2598 -------------------------------------------------------------------------------- MB 4.837^ # | # | ::::# @ | @: : #: @ ::: | @@:@@: : #::::@:@@:::::: | ::::@@@ :@@: : #:: :@:@ :: ::: @: | @::: ::@@@ :@@: : #:: :@:@ :: :::: @: | @::@: : ::@@@ :@@: : #:: :@:@ :: :::::@: | :::@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@: | :@:: :@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@: | ::@:: :@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@: | @@::@:: :@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@: | @@ ::@:: :@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@: : | ::@@ ::@:: :@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@::: | @ @@ ::@:: :@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@::: | ::@ @@ ::@:: :@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@::: | @::: @ @@ ::@:: :@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@::: | ::@::: @ @@ ::@:: :@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@::: | @: @::: @ @@ ::@:: :@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@::: | @@@@: @::: @ @@ ::@:: :@::@: : ::@@@ :@@: : #:: :@:@ :: :::::@::: 0 +----------------------------------------------------------------------->Gi 0 1.554 Number of snapshots: 61 Detailed snapshots: [6, 7, 8, 10, 14, 16, 17, 20, 24, 27, 32, 33, 34, 36, 37, 4 0 (peak), 44, 46, 56]
What version of glibc, btw? Reproduced with: glibc-2.12.90-10.x86_64 gdb-7.2-23.fc14.x86_64 gdb-heap-0.5-2.fc14.x86_64 thunderbird-3.1.6-1.fc14.x86_64 [david@f14 ~]$ gdb attach $(pidof thunderbird-bin) (gdb) heap Domain Kind Detail Count Allocated size ------ ---- ------ ----- -------------- TOTAL 0 0 gdb-heap reads from these globals, which appear to still be in their initial zero-filled state: (gdb) p main_arena $1 = {mutex = 0, flags = 0, fastbinsY = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, top = 0x0, last_remainder = 0x0, bins = {0x0 <repeats 254 times>}, binmap = {0, 0, 0, 0}, next = 0x0, next_free = 0x0, system_mem = 0, max_system_mem = 0} (gdb) p mp_ $2 = {trim_threshold = 0, top_pad = 0, mmap_threshold = 0, arena_test = 0, arena_max = 0, n_mmaps = 0, n_mmaps_max = 0, max_n_mmaps = 0, no_dyn_threshold = 0, pagesize = 0, mmapped_mem = 0, max_mmapped_mem = 0, max_total_mem = 0, sbrk_base = 0x0} In particular, main_arena.next is 0x0 Looking in F14's glibc, I see usage of: #define arena_lookup(ptr) do { \ Void_t *vptr = NULL; \ ptr = (mstate)tsd_getspecific(arena_key, vptr); \ } while(0) so I believe the issue is that gdb-heap doesn't yet know about thread-specific arenas.
Given: #ifdef PER_THREAD /* Linked list for free arenas. */ struct malloc_state *next_free; #endif and the presence of "next_free" above in "main_arena", it looks like this build of the code has "PER_THREAD"
Another problem may be all the xulrunner apps on Fedora use by default: --enable-jemalloc Replace memory allocator with jemalloc I had to disable it in a custom build when chasing some Firefox memory problems. Another unrelated issue is that glibc malloc should be tuned to be on par with the jemalloc performance for xulrunner apps.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping