296626 - Deer Park crashes, when loads xml with xsl stylesheet(transforming to svg) crash [@ nsStyleContext::ApplyStyleFixups a00d3007 ]

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[sendmail.to]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050603 Firefox/1.0+

See attached files, wenn loading test.xml file, Deer Park will crash.
(I will attach also the detail.txt from the Feddback Agent if no one can
reproduce this Bug.)

Reproducible: Always

Steps to Reproduce:
1. Open Deer Park
2. load the _test_.xml file via Drag and Drop or URI
3. Deer Park crashes

Comment 1

[sendmail.to]

Attachment: Test XML File

Comment 2

[sendmail.to]

Attachment: Test XSL File

Comment 3

[Jaime Mitchell (use [e-mail] for email)]

Could you post the talkback id please from

/components/talkback.exe

Comment 4

[sendmail.to]

I didn't send a "talkback-package", because of no Internet Conection at the
testing PC.
But i have saved the Output in a file.

Comment 5

[Jaime Mitchell (use [e-mail] for email)]

I managed to get the files to run locally, will try to fix the test cases so
they run online.

Firefox crashes with TB - TB6386078X

-> New

Comment 6

[Jaime Mitchell (use [e-mail] for email)]

Talkback Data

Stack Signature	 nsStyleContext::ApplyStyleFixups a00d3007
Product ID	FirefoxTrunk
Build ID	2005060306
Trigger Time	2005-06-04 09:28:36.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (001ec32f)
URL visited	
User Comments	
Since Last Crash	8580 sec
Total Uptime	8580 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/style/nsStyleContext.cpp,
line 360
Stack Trace 	
nsStyleContext::ApplyStyleFixups 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/style/nsStyleContext.cpp,
line 360]
nsCSSFrameConstructor::ConstructMathMLFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 6816]
nsCSSFrameConstructor::ConstructHTMLFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 5263]
nsCSSFrameConstructor::ConstructFrameInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 7630]
nsCSSFrameConstructor::ConstructFrameInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 7538]
nsCSSFrameConstructor::WrapFramesInFirstLineFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 11868]
nsCSSFrameConstructor::ConstructPageBreakFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 7447]
nsCSSFrameConstructor::ConstructFrameInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 7664]
nsCSSFrameConstructor::ConstructFrameInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 7538]
nsCSSFrameConstructor::WipeContainingBlock 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 13168]
nsCSSFrameConstructor::ConstructInline 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 12982]
nsCSSFrameConstructor::InitAndRestoreFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 6732]
nsCSSFrameConstructor::ReconstructDocElementHierarchy 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 7743]
nsCSSFrameConstructor::ConstructFrameInternal 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 7538]
nsCSSFrameConstructor::WrapFramesInFirstLineFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 11868]
nsCSSFrameConstructor::ConstructRootFrame 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 4485]
nsCSSFrameConstructor::ContentInserted 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 9059]
PresShell::InitialReflow 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp,
line 2898]
nsXBLWindowDragHandler::nsXBLWindowDragHandler 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xbl/src/nsXBLWindowDragHandler.cpp,
line 57]
nsXMLContentSink::HandleStartElement 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xml/document/src/nsXMLContentSink.cpp,
line 940]
nsXMLContentSink::CloseElement 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/content/xml/document/src/nsXMLContentSink.cpp,
line 478]
txMozillaTextOutput::`scalar deleting destructor'
txMozillaXMLOutput::endElement 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/extensions/transformiix/source/xslt/txMozillaXMLOutput.cpp,
line 270]
txExecutionState::getVariable 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/extensions/transformiix/source/xslt/txExecutionState.cpp,
line 239]
txMozillaXSLTProcessor::ImportStylesheet 
[c:/builds/tinderbox/Fx-Trunk/WINNT_5.2_Depend/mozilla/extensions/transformiix/source/xslt/txMozillaXSLTProcessor.cpp,
line 353]

Comment 7

[Jaime Mitchell (use [e-mail] for email)]

Stack suggests this is a dupe of bug 284889

Comment 8

[Jaime Mitchell (use [e-mail] for email)]

Attachment: XSL File for text case

Comment 9

[Jaime Mitchell (use [e-mail] for email)]

Attachment: Test Case

Comment 10

[Boris Zbarsky [:bzbarsky]]

You really want to reassign core bugs like this out of the Firefox product if
you want someone to look at them (eg I'm pretty close to automatically sending
all Firefox-product bugmail to /dev/null).

That said, before the crash I get the following:

###!!! ASSERTION: invalid container: 'Error', file
../../../../../mozilla/layout/svg/base/src/nsSVGPathGeometryFrame.cpp, line 851
###!!! ASSERTION: Null outerSVGFrame: 'Error', file
../../../../../mozilla/layout/svg/base/src/nsSVGPathGeometryFrame.cpp, line 787

(so we seem to have some invalid SVG here....)  This is repeated 5 or 6 times. 
Then I get:

###!!! ASSERTION: No style context found!: 'mStyleContext', file
../../../mozilla/layout/generic/nsIFrame.h, line 606

And then:

Program received signal SIGSEGV, Segmentation fault.
(gdb) frame
#0  0xb608e02b in nsCachedStyleData::GetStyleData (this=0x1c, aSID=@0xbfffcf90)
    at nsRuleNode.h:210

Note the bogus |this| pointer.  More precisely, we have an nsSVGGlyphFrame with
a null mStyleContext.  This happens because nsSVGGlyphFrame::Init bails out with
NS_ERROR_FAILURE before setting mStyleContext if it has no outer SVG frame.  But
nsCSSFrameConstructor::ConstructTextFrame (which is what constructs glyph
frames) never checks the rv of InitAndRestoreFrame, so the not-initialized frame
happily ends up in the tree and later crashes.

First we should always make sure to set mStyleContext before bailing out of Init
(anything done by nsFrame::Init MUST be done before local init starts,
basically; I realize that the current design of the SVG frame stuff makes this
really hard, which is why nsFrame::Init isn't even being called).  Second, the
caller should check the rv of InitAndRestoreFrame and do something sane.

Oh, and this isn't related to bug 284889.

Comment 11

[Benjamin Smedberg]

Boris/dbaron/tor/jwatt, what can we do for 1.8 here?

Comment 12

[tor]

Attachment: get the frame in a usable state, delete if Init failed

Comment 13

[Brendan Eich [:brendan]]

Comment on attachment 187720 [details] [diff] [review]
get the frame in a usable state, delete if Init failed

Sounds like this is a good thing to get into 1.8b3, but bz said "we probably
have other similar bugs lurking around".  Should another bug be on file?

/be

Comment 14

[tor]

Checked in.  Bug 299351 filed to remind us that we should doublecheck the rest
of the svg frames.

Comment 15

[tor]

*** Bug 296806 has been marked as a duplicate of this bug. ***