Enabling profiling causes hang?

[Brock Pytlik]

I think these are the relevant lines from config.log:

> configure:8897: checking configured backtracing method
> configure:8899: result: libgcc


I see the same lines for both the x86 and arm builds.

Brock

On Wed, Feb 11, 2015 at 3:36 PM, Jason Evans <jasone at canonware.com> wrote:

> On Feb 11, 2015, at 2:49 PM, Brock Pytlik <brock.pytlik at gmail.com> wrote:
> > So I think we're closing in on the finish line. I've successfully
> generated profiles from ardb using the gate tip malloc. The problem I'm
> having is that pprof (the one distributed w/ jemalloc) shows no allocation
> information. (I use the one distributed w/ jemalloc b/c the one that's part
> of gperftools 2.4 doesn't know about heap_v2 afaict.) To be clear, pprof
> loads the file, then I do "top" and it says '0 B', as does "top --cum".
> >
> > I haven't found documentation about what the heap_v2 file format is, so
> I'm not sure where the problem is. I've included what one of the profile
> files looks like. If you can point me to the documentation for the heap_v2
> file format that would be great, then I could possibly interpret what's
> below. If you know what's going on when you look @ the file below, that
> would be great as well.
> >
> > heap_v2/524288
> >   t*: 217: 3029560 [0: 0]
> >   t0: 6: 1015808 [0: 0]
> >   t1: 0: 0 [0: 0]
> >   t2: 207: 1440312 [0: 0]
> >   t3: 0: 0 [0: 0]
> >   t4: 0: 0 [0: 0]
> >   t5: 0: 0 [0: 0]
> >   t6: 0: 0 [0: 0]
> >   t7: 4: 573440 [0: 0]
> > @
> >   t*: 217: 3029560 [0: 0]
> >   t0: 6: 1015808 [0: 0]
> >   t2: 207: 1440312 [0: 0]
> >   t7: 4: 573440 [0: 0]
>
> The line that starts with @ should also have a sequence of hex addresses
> (the backtrace).  For some reason you appear to be getting zero-length
> (i.e. failed) backtraces, which means that all samples are being merged
> into a single record.  Which backtracing mechanism are you using?  See the
> configure output to determine whether libunwind, libgcc, or gcc intrinsics
> are being used.
>
> Thanks,
> Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jemalloc.net/mailman/jemalloc-discuss/attachments/20150211/e45b726e/attachment.html>