Closed Bug 712224 Opened 12 years ago Closed 12 years ago

Make jprof generate output that can be parsed by the 'cleopatra' front-end viewer

Categories

(Core :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla12

People

(Reporter: jesup, Assigned: jesup)

Details

Attachments

(1 file)

BenWa has a viewer for call-stack data called cleopatra - make jprof generate compatible output for that.
use '--cleo' to get the output; note that other options like --thread are still available, though not all make sense and some may produce odd results.  Note also that the symbols include args (important in that some names map to more than one function based on args)
Comment on attachment 583086 [details] [diff] [review]
working patch to generate cleopatra output

Requesting r (or rs) from dbaron - not part of the build so risk is zip, even if I fubarred the patch (and it seems to work fine).

FYI, you can drop data into the cleopatra front-end here:
http://varium.fantasytalesonline.com/cleopatra/
Attachment #583086 - Flags: review?(dbaron)
Comment on attachment 583086 [details] [diff] [review]
working patch to generate cleopatra output

rubber-stamp r=dbaron

I'm tempted to complain about following local style, but I can't tell what local style in this file is (e.g., "if(" vs. "if (" and whether the opening { after an if or else goes on the same line or its own line).
Attachment #583086 - Flags: review?(dbaron) → review+
Heads up we will change the URL in the future.

Also as we change the front end we will be adding additional features that may not make sense with the output produced from jprof (while I hope that most will just transparently benefits this output). 

It may make sense to add in tags so that you can disable feature in the visualization that don't make sense for jprof. Something like 'meta-Disable unknown' or something.
(In reply to David Baron [:dbaron] from comment #3)
> I'm tempted to complain about following local style, but I can't tell what
> local style in this file is (e.g., "if(" vs. "if (" and whether the opening
> { after an if or else goes on the same line or its own line).

The style is already mildly mixed in leaky.cpp; all the new bits I added were "normal" style, but the part that's cut-and-pasted I didn't touch style on.  At some point I may assert style on the file, but I dislike doing that because it messes up history annotation.
https://hg.mozilla.org/mozilla-central/rev/0673da2a834a
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla12
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: