Crash when doing document.write[ln] in an XSLT stylesheet [@ txMozillaXMLOutput::endHTMLElement]

RESOLVED FIXED

Status

()

Core
XSLT
--
critical
RESOLVED FIXED
14 years ago
3 years ago

People

(Reporter: Martin Honnen, Unassigned)

Tracking

({crash, testcase})

Trunk
crash, testcase
Points:
---
Bug Flags:
wanted-next +
blocking1.9.2 -
wanted1.9.2 +

Firefox Tracking Flags

(blocking2.0 alpha1+)

Details

(Whiteboard: read URL for workaround, crash signature, URL)

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

14 years ago
I will upload the XML and XSLT files causing the crash.
Crash happens with Mozilla 1.3 release and Mozilla 1.4a release on Win 98.
There should be talkback data as I filled out the talkback dialogs when the
browsers crashed.
The XML is transformed and rendered without problems in IE6.
(Reporter)

Comment 1

14 years ago
Created attachment 121175 [details]
XSLT stylesheet causing the crash
(Reporter)

Comment 2

14 years ago
Created attachment 121177 [details]
test case (load and Mozilla 1.3 and 1.4a crash)
(Reporter)

Comment 3

14 years ago
Talkback ids: TB19347247Z, TB19347081H

Comment 4

14 years ago
crash using nightly 2003042005 on Linux and a debug build (CVS 20030420):

###!!! ASSERTION: QueryInterface needed: 'query_result.get() == mRawPtr', file
../../dist/include/xpcom/nsCOMPtr.h, line 508
Break: at file ../../dist/include/xpcom/nsCOMPtr.h, line 508
pldhash: for the table at address 0xbfffeaf0, the given entrySize of 48 probably
favors chaining over double hashing.
Error loading URL
http://bugzilla.mozilla.org/attachment.cgi?id=121177&action=view : 804b0002
###!!! ASSERTION: Please remove this from the document properly: '!mDocument',
file nsGenericElement.cpp, line 745
Break: at file nsGenericElement.cpp, line 745
###!!! ASSERTION: Please remove this from the document properly: '!mDocument',
file nsGenericElement.cpp, line 745
Break: at file nsGenericElement.cpp, line 745
###!!! ASSERTION: Unbalanced startElement and endElement calls!:
'nodeName.Equals(aName, nsCaseInsensitiveStringComparator())', file
txMozillaXMLOutput.cpp, line 237
Break: at file txMozillaXMLOutput.cpp, line 237
###!!! ASSERTION: Unbalanced startElement and endElement calls!:
'nodeName.Equals(aName, nsCaseInsensitiveStringComparator())', file
txMozillaXMLOutput.cpp, line 237
Break: at file txMozillaXMLOutput.cpp, line 237
###!!! ASSERTION: endElement'ing non-element: 'element', file
txMozillaXMLOutput.cpp, line 247
Break: at file txMozillaXMLOutput.cpp, line 247
###!!! ASSERTION: Can't QI to nsIContent: 'content', file
txMozillaXMLOutput.cpp, line 534
Break: at file txMozillaXMLOutput.cpp, line 534
###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().:
'mRawPtr != 0', file ../../../../dist/include/xpcom/nsCOMPtr.h, line 691
Break: at file ../../../../dist/include/xpcom/nsCOMPtr.h, line 691

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 1796)]
0x420c11dd in txMozillaXMLOutput::endHTMLElement (this=0x827a078,
    aElement=0x0, aXHTML=0) at txMozillaXMLOutput.cpp:537
537         content->GetTag(*getter_AddRefs(atom));
(gdb) p atom
$1 = {mRawPtr = 0x0}
(gdb) bt
#0  0x420c11dd in txMozillaXMLOutput::endHTMLElement (this=0x827a078,
    aElement=0x0, aXHTML=0) at txMozillaXMLOutput.cpp:537
#1  0x420bf588 in txMozillaXMLOutput::endElement (this=0x827a078,
    aName=@0xbfffe900, aNsID=0) at txMozillaXMLOutput.cpp:248
#2  0x420b65a6 in txEndElement::execute (this=0x8a73ff0, aEs=@0xbfffea30)
    at txInstructions.cpp:487
#3  0x420d75ca in txXSLTProcessor::execute (aEs=@0xbfffea30)
    at txXSLTProcessor.cpp:108
#4  0x420bd890 in txMozillaXSLTProcessor::DoTransform (this=0x89df838)
    at txMozillaXSLTProcessor.cpp:346
#5  0x420be51e in txMozillaXSLTProcessor::setStylesheet (this=0x89df838,
    aStylesheet=0x8a2dc60) at txMozillaXSLTProcessor.cpp:591
#6  0x420b8cc4 in txCompileObserver::onDoneCompiling (this=0x8a43fd0,
    aCompiler=0x8a2db88, aResult=0) at txMozillaStylesheetCompiler.cpp:261
#7  0x420d045e in txStylesheetCompiler::maybeDoneCompiling (this=0x8a2db88)
    at txStylesheetCompiler.cpp:510
#8  0x420d0028 in txStylesheetCompiler::doneLoading (this=0x8a2db88)
    at txStylesheetCompiler.cpp:399
#9  0x420b89aa in txStylesheetSink::DidBuildModel (this=0x8a8fde8,
    aQualityLevel=0) at txMozillaStylesheetCompiler.cpp:188
#10 0x415cdf5c in nsExpatDriver::DidBuildModel (this=0x89a8690, anErrorCode=0,
    aNotifySink=1, aParser=0x8a2e7b8, aSink=0x8a8fde8)
    at nsExpatDriver.cpp:1027
[...]
Severity: major → critical
Keywords: testcase
OS: Windows 98 → All
Summary: Crash when loading XML file containing xml-stylesheet processing instruction for an XSLT stylesheet → Crash when loading XML file containing xml-stylesheet processing instruction for an XSLT stylesheet [@ txMozillaXMLOutput::endHTMLElement ]
We're most likly falling on the document.write. document.write is not supported
(and there are currently no schedule for if/when it will be), but we should of
course make sure we don't crash.

Comment 6

14 years ago
Reproduced using FizzillaMach/2003-04-21-08-trunk, generating TB240513H. Setting
Hardware=All.
Hardware: PC → All
Summary: Crash when loading XML file containing xml-stylesheet processing instruction for an XSLT stylesheet [@ txMozillaXMLOutput::endHTMLElement ] → Crash when loading XML file containing xml-stylesheet processing instruction for an XSLT stylesheet [@ txMozillaXMLOutput::endHTMLElement]

Comment 7

14 years ago
*** Bug 207358 has been marked as a duplicate of this bug. ***

Comment 8

14 years ago
taking, I have a patch.
I merely do rewire document.write and writeln to functions that throw() a
string I get from our string bundle.
After the transform, I delete those functions, which re-exposes the native code.
That was kinda easy.
Assignee: peterv → axel

Comment 9

14 years ago
Created attachment 124764 [details] [diff] [review]
function(){throw localized not supported during transform;}

Updated

14 years ago
Attachment #124764 - Flags: superreview?(peterv)
Attachment #124764 - Flags: review?(bugmail)

Updated

14 years ago
Flags: blocking1.4?
I'm not so sure I like this way of inserting scripts by having the js-engine
evaluate strings, and then deleting them by doing the same thing again. Is this
done anywhere else in mozilla?

I'm definitly fine with doing this on the branch just to patch the crasher. But
on the trunk we should IMHO fix document.write to not crash, and possibly throw
the exception there. XHTML needs something similar iirc since document.write
doesn't work while an XHTML document is being parsed.

Comment 11

14 years ago
document.write is completely disabled for XHTML.
XSLT needs to do this just during transformation. Seems to be something different.

I see three ways to achieve this:
- hack in the js context, like attachement 124764 does.
- create a nsPIHTMLDocument, with just a CanDocumentWrite(PRBool aBool) method
- hack into nsIDocument, possibly changing IsCaseSensitive to something like
  SetFeature(PRUint32 aFeature, PRBool aEnabled) and HasFeature(PRUint32 aFeature)
  and merging casesensitivity and document.write into a bitfield.

jst, any opinion on this?

adjusting topic, obviously didn't block 1.4, if we get a plan together, we 
might improve 1.4.x
Flags: blocking1.4?
Summary: Crash when loading XML file containing xml-stylesheet processing instruction for an XSLT stylesheet [@ txMozillaXMLOutput::endHTMLElement] → Crash when when doing document.write[ln] in an XSLT stylesheet [@ txMozillaXMLOutput::endHTMLElement]

Comment 12

14 years ago
*** Bug 211503 has been marked as a duplicate of this bug. ***
i think i would prefer to see CanDocumentWrite (or something like it) to
nsIHTMLDocument

Comment 14

14 years ago
Comment on attachment 124764 [details] [diff] [review]
function(){throw localized not supported during transform;}

obviously nobody likes this
Attachment #124764 - Attachment is obsolete: true
Attachment #124764 - Flags: superreview?(peterv)
Attachment #124764 - Flags: review?(bugmail)

Comment 15

13 years ago
*** Bug 234107 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Summary: Crash when when doing document.write[ln] in an XSLT stylesheet [@ txMozillaXMLOutput::endHTMLElement] → Crash when doing document.write[ln] in an XSLT stylesheet [@ txMozillaXMLOutput::endHTMLElement]
*** Bug 240592 has been marked as a duplicate of this bug. ***

Comment 17

13 years ago
*** Bug 243863 has been marked as a duplicate of this bug. ***

Comment 18

13 years ago
document.write('<xsl:value-of />') will cause Mozilla to hang and all other tabs
will not respond. But the DOM Inspector shoes interesting results.

Comment 19

13 years ago
(In reply to comment #18)
> document.write('<xsl:value-of />') will cause Mozilla to hang and all other tabs
> will not respond. But the DOM Inspector shoes interesting results.

You deserve a cookie for creativity.
.adtech.de      TRUE    /       FALSE   1398440457      JEB2    02DD2501A03A7265
8D14369430041571

Comment 20

13 years ago
I don't have the cycles nor the idea to do this.
Assignee: axel → nobody
QA Contact: keith → core.xslt
*** Bug 248259 has been marked as a duplicate of this bug. ***

Comment 22

13 years ago
*** Bug 248550 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Whiteboard: read URL for workaround

Comment 23

13 years ago
Seeing this on Windows XP Pro SP1..
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040624
Firefox/0.9.0+

The testcase locks up Firefox. Tabs can still be closed, but other than that,
the browser isn't functional. The window closed, but firefox was still running.
I needed to ctrl+alt+del to bring up the task manager and kill it before being
able to reopen the browser.

Any takers?

Comment 24

13 years ago
Adding xmlns="http://www.w3.org/TR/xhtml1/strict" to the header prevents from
crashing but it seems as if transformation halts.

Comment 25

13 years ago
*** Bug 259730 has been marked as a duplicate of this bug. ***

Comment 26

13 years ago
*** Bug 276910 has been marked as a duplicate of this bug. ***

Comment 27

12 years ago
*** Bug 278617 has been marked as a duplicate of this bug. ***
*** Bug 281771 has been marked as a duplicate of this bug. ***
*** Bug 281683 has been marked as a duplicate of this bug. ***

Comment 30

12 years ago
*** Bug 289113 has been marked as a duplicate of this bug. ***
*** Bug 292378 has been marked as a duplicate of this bug. ***

Comment 32

12 years ago
*** Bug 297149 has been marked as a duplicate of this bug. ***

Comment 33

12 years ago
2005111804-trunk/Linux doesn't crash but loading
doesn't finish.
Is this another bug?
*** Bug 336709 has been marked as a duplicate of this bug. ***

Comment 35

11 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

Doesn't crash - loading doesn't finish just liks what Hideo said.

Comment 36

8 years ago
Is it still the case with Firefox 3.0.5 or is it just me ?
If you can't reproduce I'd say we should close it as things have changed a lot since this bug was filed

Comment 38

8 years ago
I can reproduce whenever you want. Tell me what you expect as debug or dump file and I will provide.

Comment 39

8 years ago
Bug 293347 has a reproducible testcase.  It doesn't crash in quite the same way, but that doesn't matter as long as we think the right solution is to disable document.write in XSLT (comment 11, comment 13).  Let's do that!
Blocks: 293347
Flags: blocking1.9.2?
Sure! But I'm not going to hold the release for this.
blocking2.0: --- → alpha1
Flags: wanted1.9.2+
Flags: wanted-next+
Flags: blocking1.9.2?
Flags: blocking1.9.2-

Comment 41

7 years ago
The patch in bug 293347 fixed this by not allowing document.write in pages created using XSLT.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Updated

6 years ago
Crash Signature: [@ txMozillaXMLOutput::endHTMLElement]
You need to log in before you can comment on or make changes to this bug.