<div dir="ltr">I think these are the relevant lines from config.log:<div><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">configure:8897: checking configured <span class="">back</span>tracing method<br>configure:8899: result: libgcc</blockquote><div><br></div><div>I see the same lines for both the x86 and arm builds.</div><div><br></div><div>Brock </div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 11, 2015 at 3:36 PM, Jason Evans <span dir="ltr"><<a href="mailto:jasone@canonware.com" target="_blank">jasone@canonware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Feb 11, 2015, at 2:49 PM, Brock Pytlik <<a href="mailto:brock.pytlik@gmail.com">brock.pytlik@gmail.com</a>> wrote:<br>
> 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".<br>
><br>
> 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.<br>
><br>
> heap_v2/524288<br>
>   t*: 217: 3029560 [0: 0]<br>
>   t0: 6: 1015808 [0: 0]<br>
>   t1: 0: 0 [0: 0]<br>
>   t2: 207: 1440312 [0: 0]<br>
>   t3: 0: 0 [0: 0]<br>
>   t4: 0: 0 [0: 0]<br>
>   t5: 0: 0 [0: 0]<br>
>   t6: 0: 0 [0: 0]<br>
>   t7: 4: 573440 [0: 0]<br>
> @<br>
>   t*: 217: 3029560 [0: 0]<br>
>   t0: 6: 1015808 [0: 0]<br>
>   t2: 207: 1440312 [0: 0]<br>
>   t7: 4: 573440 [0: 0]<br>
<br>
</span>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.<br>
<br>
Thanks,<br>
Jason</blockquote></div><br></div>