Confirmed users
1,345
edits
Performance:Leak Tools: Difference between revisions
Jump to navigation
Jump to search
→Post-processing of stack traces
Amccreight (talk | contribs) (→Cycle collector heap dump: update various information on CC heap dumps) |
Nnethercote (talk | contribs) |
||
| Line 237: | Line 237: | ||
== Post-processing of stack traces == | == Post-processing of stack traces == | ||
On Mac and Linux, the stack traces generated by our internal debugging tools don't have very good symbol information (since they just show the results of <code>dladdr</code>). The stacks can be significantly improved (better symbols, and file name / line number information) by post-processing. Stacks can be piped through the scripts <code>mozilla/tools/rb/ | On Mac and Linux, the stack traces generated by our internal debugging tools don't have very good symbol information (since they just show the results of <code>dladdr</code>). The stacks can be significantly improved (better symbols, and file name / line number information) by post-processing. Stacks can be piped through the scripts <code>mozilla/tools/rb/fix_linux_stack.py</code> or <code>mozilla/tools/rb/fix_macosx_stack.py</code> to do this. These scripts are designed to be run on balance trees in addition to raw stacks; since they are rather slow, it is often '''much faster''' to generate balance trees (e.g., using <code>make-tree.pl</code> for the refcount balancer or <code>diffbloatdump.pl --use-address</code> for trace-malloc) and ''then'' run the balance trees (which are much smaller) through the post-processing. | ||
== Getting symbol information for system libraries == | == Getting symbol information for system libraries == | ||