Closed Bug 429963 Opened 12 years ago Closed 10 years ago

Please update fix-macosx-stack.pl for Mac 10.5

Categories

(Core :: XPCOM, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED

People

(Reporter: cbook, Unassigned)

References

()

Details

Attachments

(1 file, 1 obsolete file)

According to http://wiki.mozilla.org/Performance:Leak_Tools#Post-processing_of_stack_traces the fix-macos-stack.pl script has not been updated for the debugging format on Mac 10.5 so far. 

Maybe we should update this script also now for Mac 10.5 to provide better stacks for bugs like Bug 427657
I believe the only thing that's broken at the moment is the filename/lineno information. The symbol names are usually correct.
The stack in bug 429962 looks totally bogus, including the symbol names.
The stack in that bug looks like it hasn't been run through fix-macosx-stack.pl at all.  It still has the square-bracket parts, which fix-macosx-stack.pl uses and removes.
Summary: Please update fix-macos-stack.pl for Mac 10.5 → Please update fix-macosx-stack.pl for Mac 10.5
The script is broken because nm no longer outputs SLINE entries on 10.5. It could probably be fixed by using 'atos' in a way similar to how fix-linux-stack.pl uses 'addr2line'.
Attached patch work in progress (obsolete) — Splinter Review
Thanks, I didn't know about atos (despite spending a good bit of time looking for an addr2line equivalent).

This is work in progress on converting; it doesn't work for me, though.  I suspect the problem has something to do with buffered I/O on the pipe, since it just hangs waiting for atos to output something.  I guess I need to read up on the relevant bits of perl...
Component: Testing → XPCOM
QA Contact: testing → xpcom
I translated the above into python, and that didn't fix the buffering problem.

So I landed the python translation with the atos process caching disabled (which makes it really really slow):
http://hg.mozilla.org/mozilla-central/rev/ec146a976e99
but now at least there's *something* in the tree that should be functional on 10.5.  (However, I was actually testing on 10.4.)
http://stackoverflow.com/questions/1544050/force-another-programs-standard-output-to-be-unbuffered-using-python suggests using the python "pty" module to trick subprocesses into using unbuffered output.
Attachment #340732 - Attachment is obsolete: true
Btw, some of the output is slightly wrong on 10.5.  I think these problems existed before my patch as well.

In this example, it looks like atos gave us a demangled name, but we passed it to cxxfilt() anyway, and lost the first letter as a result:

sGfxScrollFrameInner::ScrollToImpl(nsPoint) (nsGfxScrollFrame.cpp:1764, in XUL)

In this example, the space between the two arguments prevented us from matching atos_sym_re, so we didn't pass it through cxxfilt(), and also didn't combine the filename with the "in XUL" part:

nsGfxScrollFrameInner::ScrollTo(nsPoint, nsIScrollableFrame::ScrollMode) (in XUL) (nsGfxScrollFrame.cpp:1355)
Checked in the patch in comment 8:
http://hg.mozilla.org/mozilla-central/rev/056547dd3825

I'm calling this bug fixed.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Can you file a followup on fixing automation.py to use the new python script on OS X?
Filed bug 539514 on the first problem in comment 9.
Blocks: 539516
Filed bug 539516 on updating automation.py.

Filed bug 539518 on removing fix-macosx-stack.pl.
Blocks: 547793
You need to log in before you can comment on or make changes to this bug.