Crash [@ nsSVGFilterProperty::GetFilterFrame] with filter, MathML

VERIFIED FIXED in mozilla1.9.1b3

Status

()

Core
Layout
--
critical
VERIFIED FIXED
10 years ago
4 years ago

People

(Reporter: Jesse Ruderman, Assigned: longsonr)

Tracking

(Blocks: 2 bugs, 4 keywords)

Trunk
mozilla1.9.1b3
assertion, crash, testcase, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical], crash signature)

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

10 years ago
Created attachment 343073 [details]
testcase

Loading the testcase triggers three assertions and a scary crash.

###!!! ASSERTION: frame was not removed from primary frame map before destruction or was readded to map after being removed: 'Not Reached', file /Users/jruderman/central/layout/base/nsFrameManager.cpp, line 720

###!!! ASSERTION: GetPrimaryFrameFor() called while frames are being destroyed!: '!mIsDestroyingFrames', file /Users/jruderman/central/layout/base/nsFrameManager.cpp, line 328

###!!! ASSERTION: Cached frame is incorrect!: 'mElement.get() && static_cast<nsGenericElement*>(mElement.get())->GetPrimaryFrame() == mReferencedFrame', file /Users/jruderman/central/layout/svg/base/src/nsSVGEffects.cpp, line 78

Crash with nsSVGFilterProperty::GetFilterFrame calling 0xdddddddd.
Flags: blocking1.9.1?
(Reporter)

Updated

10 years ago
Whiteboard: [sg:critical]
(Assignee)

Comment 1

10 years ago
Probably the same issue as bug 458493 and bug 455314.
(Assignee)

Comment 2

10 years ago
See bug 455314 comment 9 for analysis.
(Assignee)

Comment 3

10 years ago
Created attachment 344482 [details] [diff] [review]
patch
Assignee: nobody → longsonr
Attachment #344482 - Flags: superreview?(roc)
Attachment #344482 - Flags: review?(roc)
(Assignee)

Comment 4

10 years ago
This patch does not fix bug 455314 nor does it fix bug 454945 perhaps the patch in bug 458453 would fix those.
(Assignee)

Comment 5

10 years ago
I'll do s/Ensure that the filter's is/Ensure that the filter is/ on check in.
Comment on attachment 344482 [details] [diff] [review]
patch

+  // Ensure that the filter's is repainted correctly

s/filters's/filter/
Attachment #344482 - Flags: superreview?(roc)
Attachment #344482 - Flags: superreview+
Attachment #344482 - Flags: review?(roc)
Attachment #344482 - Flags: review+
(Assignee)

Comment 7

10 years ago
Checked in http://hg.mozilla.org/mozilla-central/rev/678883a079ba
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Blocks: 458453
Flags: blocking1.9.1? → blocking1.9.1+
(Assignee)

Updated

9 years ago
Depends on: 473273
Robert, how can I verify this fix? I cannot get crashed an older build with the attached testcase on OS X nor Windows.
Flags: in-testsuite?
Target Milestone: --- → mozilla1.9.1b3
(Assignee)

Comment 9

9 years ago
It certainly used to crash for me without this fix on Windows.
Ok, I was able to crash Firefox with a debug build without this patch. The crashes don't happen anymore with builds after the patch went in.

Jesse, the assertions still happen. Shall we handle those in a separate bug?
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
OS: Mac OS X → All
Hardware: x86 → All
(Reporter)

Comment 11

9 years ago
I only see these assertions now:

###!!! ASSERTION: GetPrimaryFrameFor() called while frames are being destroyed!: '!mIsDestroyingFrames', file /Users/jruderman/central/layout/base/nsFrameManager.cpp, line 336

###!!! ASSERTION: frame was not removed from primary frame map before destruction or was readded to map after being removed: 'Not Reached', file /Users/jruderman/central/layout/base/nsFrameManager.cpp, line 734

The first could be bug 459666, but the second one is only covered by -moz-column bugs.  I don't think it's worth filing a new bug now, especially since it would have to be security-sensitive.  I'll retest when bug 459666 is fixed.
Created attachment 361218 [details]
Stack of assertion GetPrimaryFrameFor

Jesse, the stack looks completely different from the one on bug 459666. See the attachment. Are you sure that I should not file a new bug on that?
(Reporter)

Comment 13

9 years ago
Created attachment 361238 [details]
Stack of assertion GetPrimaryFrameFor (using fix-macosx-stack.pl)

You have to run tools/rb/fix-macosx-stack.pl to turn the XPCOM_DEBUG_BREAK=trap output into a useful stack trace.  (I don't know why XPCOM_DEBUG_BREAK bothers trying to print functions names at all, given how wrong they are.)
Attachment #361218 - Attachment is obsolete: true
(Reporter)

Comment 14

9 years ago
But you're right, the stacks do look different.  I filed bug 477569.
Crash Signature: [@ nsSVGFilterProperty::GetFilterFrame]
Group: core-security
Landed the crashtest:
https://hg.mozilla.org/integration/mozilla-inbound/rev/cc86e0fcb91b
Flags: in-testsuite? → in-testsuite+
You need to log in before you can comment on or make changes to this bug.