Closed
Bug 459883
Opened 16 years ago
Closed 16 years ago
Crash [@ nsSVGFilterProperty::GetFilterFrame] with filter, MathML
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
VERIFIED
FIXED
mozilla1.9.1b3
People
(Reporter: jruderman, Assigned: longsonr)
References
Details
(4 keywords, Whiteboard: [sg:critical])
Crash Data
Attachments
(3 files, 1 obsolete file)
471 bytes,
application/xhtml+xml
|
Details | |
2.12 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
3.89 KB,
text/plain
|
Details |
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•16 years ago
|
Whiteboard: [sg:critical]
Assignee | ||
Comment 1•16 years ago
|
||
Probably the same issue as bug 458493 and bug 455314.
Assignee | ||
Comment 2•16 years ago
|
||
See bug 455314 comment 9 for analysis.
Assignee | ||
Comment 3•16 years ago
|
||
Assignee: nobody → longsonr
Attachment #344482 -
Flags: superreview?(roc)
Attachment #344482 -
Flags: review?(roc)
Assignee | ||
Comment 4•16 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•16 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•16 years ago
|
||
Checked in http://hg.mozilla.org/mozilla-central/rev/678883a079ba
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Flags: blocking1.9.1? → blocking1.9.1+
Keywords: fixed1.9.1
Comment 8•15 years ago
|
||
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•15 years ago
|
||
It certainly used to crash for me without this fix on Windows.
Comment 10•15 years ago
|
||
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•15 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.
Comment 12•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
But you're right, the stacks do look different. I filed bug 477569.
Updated•13 years ago
|
Crash Signature: [@ nsSVGFilterProperty::GetFilterFrame]
Updated•11 years ago
|
Group: core-security
Comment 15•10 years ago
|
||
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.
Description
•