Hi,<br><br>I am attaching a patch that allows to iterate over all objects.<br><br>This is not a request for upstreaming: these patches cause crashes and I need help understanding these. And even if it didn't crash, this patch causes a severe overhead in memory usage and no attempt has been made to mitigate it. The goal of this effort is to allow custom developer builds of Firefox to introspect their own allocated blocks.<br>
<br>The patch (attached to this email) works by renaming the public functions such as je_malloc() to real_je_malloc() and implementing custom je_malloc() to allocate a larger block, and use the extra space to store the data of a doubly-linked list element.<br>
<br>In principle, this should be entirely transparent to the user (except for the increased memory usage), so I don't understand the crashes.<br><br>The crashes aren't immediate: I can run Firefox (this patch if for Firefox's copy of jemalloc 3.0) for a while and browse a few pages without crashing.<br>
<br>The crashes are assertion failures like this:<br><br>Program received signal SIGSEGV, Segmentation fault.<br>0x0000000000411605 in moz_abort ()<br> at /hack/mozilla-central/memory/build/extraMallocFuncs.c:116<br>116 MOZ_CRASH();<br>
(gdb) bt<br>#0 0x0000000000411605 in moz_abort ()<br> at /hack/mozilla-central/memory/build/extraMallocFuncs.c:116<br>#1 0x000000000041afdf in arena_bin_malloc_hard (arena=0x7ffff6c00180, bin=0x7ffff6c007c8)<br> at /hack/mozilla-central/memory/jemalloc/src/src/arena.c:1189<br>
#2 0x000000000041b225 in arena_tcache_fill_small (arena=0x7ffff6c00180, <br> tbin=0x7ffff6b02148, binind=9, prof_accumbytes=0)<br> at /hack/mozilla-central/memory/jemalloc/src/src/arena.c:1232<br>#3 0x000000000043c239 in tcache_alloc_small_hard (tcache=0x7ffff6b02000, <br>
tbin=0x7ffff6b02148, binind=9)<br> at /hack/mozilla-central/memory/jemalloc/src/src/tcache.c:72<br>#4 0x000000000043b7dc in tcache_alloc_small (tcache=0x7ffff6b02000, size=160, zero=false)<br> at /hack/mozilla-central/memory/jemalloc/src/include/jemalloc/internal/tcache.h:302<br>
#5 0x0000000000412c26 in arena_malloc (arena=0x0, size=160, zero=false, try_tcache=true)<br> at /hack/mozilla-central/memory/jemalloc/src/include/jemalloc/internal/arena.h:869<br>#6 0x000000000042dce8 in imalloc (size=160)<br>
at src/include/jemalloc/internal/jemalloc_internal.h:735<br>#7 0x000000000043111c in real_je_malloc (size=160)<br> at /hack/mozilla-central/memory/jemalloc/src/src/jemalloc.c:829<br>#8 0x0000000000432fa3 in malloc (size=128)<br>
at /hack/mozilla-central/memory/jemalloc/src/src/jemalloc.c:1425<br>#9 0x00007ffff7fe803c in moz_xmalloc (size=128)<br> at /hack/mozilla-central/memory/mozalloc/mozalloc.cpp:57<br>#10 0x00007ffff2dcb74d in nsTArrayInfallibleAllocator::Malloc (size=128)<br>
at ../../dist/include/nsTArray.h:56<br>...<br><br>Printing some variables here:<br><br>(gdb) up<br>#1 0x000000000041afdf in arena_bin_malloc_hard (arena=0x7ffff6c00180, bin=0x7ffff6c007c8)<br> at /hack/mozilla-central/memory/jemalloc/src/src/arena.c:1189<br>
1189 assert(bin->runcur->nfree > 0);<br>(gdb) p bin<br>$1 = (arena_bin_t *) 0x7ffff6c007c8<br>(gdb) p *bin<br>$2 = {lock = {lock = {__data = {__lock = 1, __count = 0, __owner = 6469, __nusers = 1, <br>
__kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, <br> __size = "\001\000\000\000\000\000\000\000E\031\000\000\001", '\000' <repeats 26 times>, __align = 1}}, runcur = 0x7fffc2ced000, runs = {rbt_root = 0x7fffca3004d8, rbt_nil = {{<br>
u = {rb_link = {rbn_left = 0x7ffff6c00800, rbn_right_red = 0x7ffff6c00800}, <br> ql_link = {qre_next = 0x7ffff6c00800, qre_prev = 0x7ffff6c00800}}, <br> prof_ctx = 0x7ffff6c00800}, bits = 0}}, stats = {allocated = 8896000, <br>
nmalloc = 197757, ndalloc = 142157, nrequests = 300344, nfills = 5545, <br> nflushes = 2848, nruns = 2802, reruns = 5838, curruns = 1143}}<br>(gdb) p bin->runcur<br>$3 = (arena_run_t *) 0x7fffc2ced000<br>(gdb) p *(bin->runcur)<br>
$4 = {bin = 0x7ffff6c007c8, nextind = 4544384, nfree = 0}<br><br>Any help would be greatly appreciated.<br><br>Thanks,<br>Benoit<br>