Closed Bug 793109 Opened 9 years ago Closed 9 years ago

Stacks truncated near nsDocLoader::DoFireOnStateChange

Categories

(Toolkit :: Crash Reporting, defect)

x86_64
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla19

People

(Reporter: jruderman, Assigned: espindola)

References

Details

Attachments

(4 files)

Now that bug 787302 is fixed, I'm getting better stacks, but they're still not getting all the way to main.
This is with minidump_stackwalk on a debug build from Tinderbox.
Attached file full stack
This is with gdb on a local debug build (built with Clang).
The interesting bits are:

gdb:

#35 0x00000001029cb602 in nsDocShell::OnStateChange (this=0x11b09ed30, aProgress=0x11b09ed58, aRequest=0x10c13ca58, aStateFlags=131088, aStatus=0) at /Users/jruderman/trees/mozilla-central/docshell/base/nsDocShell.cpp:6240
#36 0x00000001029cb945 in non-virtual thunk to nsDocShell::OnStateChange(nsIWebProgress*, nsIRequest*, unsigned int, unsigned int) () at /Users/jruderman/trees/mozilla-central/docshell/base/nsDocShell.cpp:675
#37 0x0000000102a07ac9 in nsDocLoader::DoFireOnStateChange (this=0x11b09ed30, aProgress=0x11b09ed58, aRequest=0x10c13ca58, aStateFlags=@0x7fff5fbfc934, aStatus=0) at /Users/jruderman/trees/mozilla-central/uriloader/base/nsDocLoader.cpp:1351

minidump_stackwalk:

33  XUL!nsDocShell::OnStateChange [nsDocShell.cpp : 6240 + 0x11]
    rbx = 0xfffdffef   r12 = 0x04b89258   r13 = 0x054aace0   r14 = 0x054aad08
    r15 = 0x00000000   rip = 0x02037ca7   rsp = 0x5fbfca00   rbp = 0x5fbfcba0
    Found by: call frame info
34  XUL + 0x1037d3f
    rbx = 0x5fbfcc28   r12 = 0x054ab7b0   r13 = 0x5fbfcc28   r14 = 0x054d7fc8
    r15 = 0x00000000   rip = 0x02037d40   rsp = 0x5fbfcbb0   rbp = 0x5fbfcbb0
    Found by: call frame info
35  XUL!nsDocLoader::DoFireOnStateChange [nsDocLoader.cpp : 1351 + 0x23]
    rip = 0x02063b94   rsp = 0x5fbfcbc0
    Found by: stack scanning

So looks like there is some problem walking past thunks. Where can I get the minidump and sym filles to reproduce this locally?
Don't worry about the minidump, I think I found the bug.
Assignee: nobody → respindola
Status: NEW → ASSIGNED
This should be fixed in clang r164411. I wil keep this bug open while I figure out the best way to deploy the fix.
This patch updates the clang build script to 164411 and removes the two patches that had been backported. This patch also:

* Remove patches that were needed on centos5 but not 6 (gnu89 and old ld).
* Builds stage one /usr/bin/gcc
* Since this gcc doesn't miscompile clang, the stage1 can be built with optimizations.
Attachment #669659 - Flags: review?(rail)
Attachment #669659 - Flags: review?(rail) → review+
These linux packages have been build on a centos6 vm.
Attachment #669664 - Flags: review?(rail)
Attachment #669664 - Flags: review?(rail) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/9444fc718d81
https://hg.mozilla.org/integration/mozilla-inbound/rev/7c60e40e92ac

The diff-talos.py results with 10 runs:

dromaeo_css
MacOSX 10.6 (rev4)                | (3175.256,     18.5116419939)  -> (3229.599,     14.1389428569)  1.0171x better
MacOSX 10.8                       | (4846.688,     10.129060047)   -> (4878.546,     14.1839960362)  1.0066x better

tp5n_paint
MacOSX 10.8                       | (178.4888,     1.04638726491)  -> (176.9359,     0.427562567831) 1.0088x better
The binaries also got a bit smaller:

 size FirefoxOld.app/Contents/MacOS/XUL 
__TEXT	__DATA	__OBJC	others	dec	hex
35753984	4911104	0	35115008	75780096	4845000
Rafaels-MacBook-Pro:t espindola$ size FirefoxNew.app/Contents/MacOS/XUL 
__TEXT	__DATA	__OBJC	others	dec	hex
35725312	4911104	0	35115008	75751424	483e000
https://hg.mozilla.org/mozilla-central/rev/9444fc718d81
https://hg.mozilla.org/mozilla-central/rev/7c60e40e92ac
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Jesse, as far as I know all the issues with bad stacks have been fixed. Please let me know if you notice something else.
Most stacks are beautiful now.  Thanks!
(In reply to Jesse Ruderman from comment #13)
> Most stacks are beautiful now.  Thanks!

Cool. BTW, bug 803184 might help with unwinding past functions in MethodJIT.cpp.
You need to log in before you can comment on or make changes to this bug.