There are three categories of improvements:
(1) using size_t* rather than unsigned long* (and "%zX" rather than
"%lX"), to better support platforms where sizeof(long) !=
sizeof(void*), such as Win64 (untested, though). This is a
non-issue for 64-bit Linux (where I tested) and Mac.
(2) Using the correct amount of 0-padding when printing addresses to
show how much memory space is being printed. In other words, using
"%016zX" on 64-bit platforms instead of "%08zX". This change is
cosmetic-only, though it makes the logs much more understandable.
(3) [in leaksoup.cpp only] Fixing an occurrence of assuming that
sizeof(int) == sizeof(void*). This occurrence led to printing only
the lower half of each word in the output, after doing a correct
analysis of the memory graph.
This patch is patching three files:
(A) nsTraceMalloc.cpp, which is the in-process Gecko trace-malloc code
that generates the memory dumps.
(B) adreader.cpp, which is shared utility code for reading such a
memory dump (currently used only by leaksoup.cpp)
(C) leaksoup.cpp, which reads in such a memory dump, performs a
strongly connected components analysis of the memory graph, and
writes it back out, HTML-ized, with the roots listed at the top.
A fourth file appears to need no modification since it only looks at the
stack part of the dump and not the contents of the memory:
(D) diffbloatdump.pl, which diffs two bloat dumps and produces a stack
tree showing the change in allocations between them
Currently we use dlsym on pthread_cond_wait$UNIX2003 to find a
function that indicates that new_sem_from_pool is on the stack. This
works on 10.5, but on 10.6 I could not find a single reliable
indicator that would work with dlsym.
The good news is that dladdr works with any symbol, not just exported
ones. To find the address of new_sem_from_pool, we set up a malloc logger
and force a call to new_sem_from_pool. From the logger callback we walk
the stack trying dladdr on every address.
To force a call to new_sem_from_pool, the initialization code has to be the
first to use semaphores, so it is now run from NS_LogInit.
This works on 10.6 and 10.5 (but we have to look for
"pthread_cond_wait$UNIX2003"). In 10.7 the call to malloc is gone, so we don't
have to worry about critical addresses on it anymore.
--HG--
extra : rebase_source : bba4ac9e3378c88f7037aa884511e473a57121f6
Currently we use dlsym on pthread_cond_wait$UNIX2003 to find a
function that indicates that new_sem_from_pool is on the stack. This
works on 10.5, but on 10.6 I could not find a single reliable
indicator that would work with dlsym.
The good news is that dladdr works with any symbol, not just exported
ones. To find the address of new_sem_from_pool, we set up a malloc logger
and force a call to new_sem_from_pool. From the logger callback we walk
the stack trying dladdr on every address.
To for a call to new_sem_from_pool, the initialization code has to be the
first to use semaphores, so it is now run from NS_LogInit.
This works on 10.6 and 10.5 (but we have to look for
"pthread_cond_wait$UNIX2003"). In 10.7 the call to malloc is gone, so we don't
have to worry about critical addresses on it anymore.
dbaron.
The 64 bit stack walks lack the InCriticalRange functionality and it looks like
the extra walks are causing an orange on leaktest on the bot.
--HG--
extra : rebase_source : 4c0a75892e30a6e522ed981a1ff12df99d2a0464
This patch disables trace malloc stacks on OS X too. To make this work,
we still have to look on the stack to decide if we must set immediate_abort,
but we can avoid other work like decoding the addresses.