Enabling profiling causes hang?

Jason Evans jasone at canonware.com
Mon Feb 9 15:23:44 PST 2015

On Feb 9, 2015, at 3:11 PM, Brock Pytlik <brock.pytlik at gmail.com> wrote:
> 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:
> 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):
> MALLOC_CONF=prof:true,lg_prof_interval:2,prof_final:false ardb-server ardb.conf

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.

> I'm confused about a couple of things:
> 1) Why it works on x86 and not arm (and whether that means the cross compiling build for arm has some issues).

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.

> 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).
> Any suggestions on where I go next?

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20150209/222bd896/attachment.html>

More information about the jemalloc-discuss mailing list