Closed
Bug 364037
Opened 18 years ago
Closed 18 years ago
xsl:copy-of a xsl:variable which contains a node crashes mozilla
Categories
(Core :: XSLT, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla1.9alpha1
People
(Reporter: ilya, Assigned: peterv)
Details
(Keywords: verified1.8.0.10, verified1.8.1.2)
Attachments
(4 files)
212 bytes,
text/xml
|
Details | |
125 bytes,
text/xml
|
Details | |
4.18 KB,
patch
|
sicking
:
review+
sicking
:
superreview+
|
Details | Diff | Splinter Review |
5.57 KB,
patch
|
jay
:
approval1.8.1.2+
jay
:
approval1.8.0.10+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060830 Firefox/1.5.0.7 (Debian-1.5.dfsg+1.5.0.7-2) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20060830 Firefox/1.5.0.7 (Debian-1.5.dfsg+1.5.0.7-2) a simple stylesheet containing <xsl:copy-of select="$x"/> with x defined as <xsl:variable name="x"><a/></xsl:variable> crashes mozilla Reproducible: Always Steps to Reproduce: 1. see attachments 2. 3. Expected Results: xsltproc said: <?xml version="1.0"?> <a/> crashes mozilla on windows and linux
Reporter | ||
Comment 1•18 years ago
|
||
Reporter | ||
Updated•18 years ago
|
Attachment #248818 -
Attachment mime type: application/xslt+xml → text/xsl
Reporter | ||
Updated•18 years ago
|
Attachment #248818 -
Attachment mime type: text/xsl → text/xml
Reporter | ||
Comment 2•18 years ago
|
||
Assignee | ||
Comment 3•18 years ago
|
||
Sigh. txCopyOf::execute flushes the buffer to the mResultHandler. mResultHandler is a txUnknownHandler, so that flushes its buffer and replaces mResultHandler with the new handler. txCopyOf::execute doesn't know that and keeps flushing to the original mResultHandler.
Assignee: xslt → peterv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 4•18 years ago
|
||
Don't really like this a lot, but it fixes the crash.
Attachment #248836 -
Flags: superreview?(bugmail)
Attachment #248836 -
Flags: review?(bugmail)
Assignee | ||
Comment 5•18 years ago
|
||
The fix works because mHandler in the Holder will be updated when creating a new handler in txUnknownHandler::createHandlerAndFlush (because mHandler will be a reference to mResultHandler where we used to crash). I thought about having createHandlerAndFlush return the new handler, that would mean changing startElement and endDocument signatures in all the handlers even though only the txUnknownHandler creates a new handler. It might be a bit clearer since it would be more explicit about what happens.
Status: NEW → ASSIGNED
Comment on attachment 248836 [details] [diff] [review] v1 It might be clearer that at least something funky is going on if you use pointer-to-pointer rather than reference-to-pointer. Also, please add documentation to txBufferingHandler describing why not a simple pointer is used.
Attachment #248836 -
Flags: superreview?(bugmail)
Attachment #248836 -
Flags: superreview+
Attachment #248836 -
Flags: review?(bugmail)
Attachment #248836 -
Flags: review+
Assignee | ||
Updated•18 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 7•18 years ago
|
||
Fixes a crash in XSLT code.
Attachment #249770 -
Flags: approval1.8.1.2?
Attachment #249770 -
Flags: approval1.8.0.10?
Comment 8•18 years ago
|
||
Comment on attachment 249770 [details] [diff] [review] v1 (branch version) Approved for both branches, a=jay for drivers.
Attachment #249770 -
Flags: approval1.8.1.2?
Attachment #249770 -
Flags: approval1.8.1.2+
Attachment #249770 -
Flags: approval1.8.0.10?
Attachment #249770 -
Flags: approval1.8.0.10+
Assignee | ||
Updated•18 years ago
|
Comment 9•18 years ago
|
||
Verified for 1.8.1.2 and 1.8.0.10 with Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.2pre) Gecko/20070105 BonEcho/2.0.0.2pre ID:2007010503 Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.10pre) Gecko/20070104 Firefox/1.5.0.10pre and also for Linux on Fedora FC 6
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•