Enabling profiling causes hang?

[Jason Evans]

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