<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Feb 9, 2015, at 3:11 PM, Brock Pytlik <<a href="mailto:brock.pytlik@gmail.com" class="">brock.pytlik@gmail.com</a>> wrote:<div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">Well, I thought it would handle what I needed, but I can't seem to get it to produce a dump. Here's what I did:<div class="">From my experiments on x86, it seems like prof:true needs to be part of MALLOC_CONF for lg_prof_interval to work at all. However, when I set prof:true on arm, ardb hangs in the atexit code. This happens even when I set prof_final to false. To be clear this command hangs (on arm):</div><div class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">MALLOC_CONF=prof:true,lg_prof_interval:2,prof_final:false ardb-server ardb.conf</blockquote></div></div></div></blockquote><div><br class=""></div><div>Oh, whoops, I forgot that in the dev branch I refactored the prof bootstrapping code to make the atexit() call conditional, but in 3.6.0 the call always happens if prof:true is set. I think you will have to hack jemalloc in order to work around this.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">I'm confused about a couple of things:</div><div class="">1) Why it works on x86 and not arm (and whether that means the cross compiling build for arm has some issues).</div></div></blockquote><div><br class=""></div><div>I haven't dug into this, but I'm assuming that this is an arbitrary implementation difference in the libc being used on ARM, possibly motivated by the desire to reduce the data segment size and only pay for internal atexit() metadata overhead if the functionality is actually used. I'm not very familiar with ARM-specific development, but I get the impression that there are multiple stripped down libc implementations in use.</div><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">If these are things that are fixed in the gate tip of jemalloc, I'd also be happy to try changing ardb to use that (assuming it's largely a drop in replacement).</div><div class=""><br class=""></div><div class="">Any suggestions on where I go next?</div></div></blockquote></div><br class=""><div class="">Assuming that your current goal is simply to get heap profiles and diagnose a leak, I'd recommend just trying to use the dev version of jemalloc. If that doesn't work for some reason, then disabling the atexit() call in jemalloc's src/prof.c and rebuilding will probably be enough to get you what you need.</div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jason</div></body></html>