Closed Bug 483444 Opened 15 years ago Closed 15 years ago

XSLT stylesheet compiler crashes

Categories

(Core :: XSLT, defect, P2)

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.1

People

(Reporter: romaxa, Assigned: peterv)

Details

(Keywords: verified1.9.0.9, verified1.9.1, Whiteboard: [sg:critical?] double free)

Attachments

(4 files, 2 obsolete files)

I don't have external URL for testcase yet, but any firefox 3.0 browser crashes on some specific testcase:
xslt/MSFT_Conformance_Tests/AttributeSets/xslt_attributeset_ImportSameName.html

#0  0xb7f1b7f2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0xb7ef9460 in raise () from /lib/i686/cmov/libpthread.so.0
#2  0xb6f0b57e in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:212
#3  <signal handler called>
#4  0x00000011 in ?? ()
#5  0xb41b9e40 in txStylesheet::addAttributeSet (this=0x8a1ac60, aAttributeSetItem=0x8ab7dd0) at ../../../../dist/include/xpcom/nsAutoPtr.h:71
#6  0xb41bbee7 in txStylesheet::doneCompiling (this=0x8a1ac60)
    at mozilla/content/xslt/src/xslt/txStylesheet.cpp:330
#7  0xb41c4e9b in txStylesheetCompiler::maybeDoneCompiling (this=0x8abf640)
    at mozilla/content/xslt/src/xslt/txStylesheetCompiler.cpp:552
#8  0xb41d32f5 in TX_CompileStylesheet (aNode=0x8cf8ea0, aProcessor=0x8ae4a00, aCallerPrincipal=0x8d36d28, aStylesheet=0x8ae4a1c)
    at mozilla/content/xslt/src/xslt/txMozillaStylesheetCompiler.cpp:809
#9  0xb41db505 in txMozillaXSLTProcessor::ImportStylesheet (this=0x8ae4a00, aStyle=0x8cf8f38)
    at mozilla/content/xslt/src/xslt/txMozillaXSLTProcessor.cpp:618
#10 0xb6f8db5f in NS_InvokeByIndex_P ()
   from obj-i386-nolibxul-buildmicrob2/dist/bin/libxpcom_core.so
#11 0xb6c30449 in XPCWrappedNative::CallMethod (ccx=@0xbff34308, mode=XPCWrappedNative::CALL_METHOD)
    at mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2424
#12 0xb6c395ba in XPC_WN_CallMethod (cx=0x89023e0, obj=0x87b5280, argc=1, argv=0x895b510, vp=0xbff34434)
---Type <return> to continue, or q <return> to quit---
    at mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1587
#13 0xb6e4a7eb in js_Invoke (cx=0x89023e0, argc=1, vp=0x895b508, flags=2)
    at mozilla/js/src/jsinterp.cpp:1312
#14 0xb6e3d6f1 in js_Interpret (cx=0x89023e0)
    at mozilla/js/src/jsinterp.cpp:5020
#15 0xb6e4a153 in js_Execute (cx=0x89023e0, chain=0x8a12640, script=0x8bd5a18, down=0x0, flags=0, result=0x0)
    at mozilla/js/src/jsinterp.cpp:1561
#16 0xb6e0a1da in JS_EvaluateUCScriptForPrincipals (cx=0x89023e0, obj=0x8a12640, principals=0x8a5ccec, chars=0x8a8e768, length=44, 
    filename=0x8a88198 "http://milosz-pc.research.nokia.com/testpages/browser/core//xslt//jsunit/app/jsUnitTestManager.js", lineno=395, rval=0x0)
    at mozilla/js/src/jsapi.cpp:5239
#17 0xb4222de6 in nsJSContext::EvaluateString (this=0x89023b0, aScript=@0xbff349cc, aScopeObject=0x8a12640, aPrincipal=0x8a5cce8, 
    aURL=0x8a88198 "http://milosz-pc.research.nokia.com/testpages/browser/core//xslt//jsunit/app/jsUnitTestManager.js", aLineNo=395, aVersion=0, 
    aRetValue=0x0, aIsUndefined=0xbff349e0)
    at mozilla/dom/src/base/nsJSEnvironment.cpp:1596
#18 0xb4230999 in nsGlobalWindow::RunTimeout (this=0x8a262f8, aTimeout=0x8bbc768)
    at mozilla/dom/src/base/nsGlobalWindow.cpp:7736
#19 0xb4230acd in nsGlobalWindow::TimerCallback (aTimer=0x8b75460, aClosure=0x8bbc768)
    at mozilla/dom/src/base/nsGlobalWindow.cpp:8087
#20 0xb6f81581 in nsTimerImpl::Fire (this=0x8b75460)
    at mozilla/xpcom/threads/nsTimerImpl.cpp:428
#21 0xb6f81648 in nsTimerEvent::Run (this=0x8b6bca0)
    at mozilla/xpcom/threads/nsTimerImpl.cpp:520
#22 0xb6f7e457 in nsThread::ProcessNextEvent (this=0x85aca70, mayWait=0, result=0xbff34ae8)
---Type <return> to continue, or q <return> to quit---
    at mozilla/xpcom/threads/nsThread.cpp:510
#23 0xb6f40647 in NS_ProcessPendingEvents_P (thread=0x85aca70, timeout=20) at nsThreadUtils.cpp:180
#24 0xb46bcff6 in nsBaseAppShell::NativeEventCallback (this=0x88d1120)
    at mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:121
#25 0xb46a4e7c in nsAppShell::EventProcessorCallback (source=0x88d1170, condition=G_IO_IN, data=0x88d1120)
    at mozilla/widget/src/gtk2/nsAppShell.cpp:69
#26 0xb777af2d in ?? () from /usr/lib/libglib-2.0.so.0
Attached file valgrind output
Attached patch v1 (obsolete) — Splinter Review
mNext is an nsAutoPtr. I'll add a testcase too.
Assignee: nobody → peterv
Status: NEW → ASSIGNED
Attachment #369368 - Flags: superreview?(jonas)
Attachment #369368 - Flags: review?(jonas)
Attachment #369368 - Flags: superreview?(jonas)
Attachment #369368 - Flags: superreview+
Attachment #369368 - Flags: review?(jonas)
Attachment #369368 - Flags: review+
Whiteboard: [sg:critical?
Group: core-security
Flags: blocking1.9.1?
Flags: blocking1.9.0.9?
Flags: blocking1.8.1.next?
Flags: blocking1.8.0.next?
Whiteboard: [sg:critical? → [sg:critical?]
Target Milestone: --- → mozilla1.9.2a1
Flags: wanted1.9.0.x+
Flags: wanted1.8.1.x+
Flags: blocking1.9.0.9?
Flags: blocking1.9.0.9+
Whiteboard: [sg:critical?] → [sg:critical?] double free
Summary: XSLT stylesheet compiler crashes. → XSLT stylesheet compiler crashes
OS: Linux → All
Hardware: Other → All
Attachment #369368 - Flags: approval1.9.0.9?
Attached patch v1 (with testcase) (obsolete) — Splinter Review
Moving reed's approval request.
Attachment #369368 - Attachment is obsolete: true
Attachment #369464 - Flags: superreview+
Attachment #369464 - Flags: review+
Attachment #369464 - Flags: approval1.9.0.9?
Attachment #369368 - Flags: approval1.9.0.9?
Attached file Testcase (CRASHES)
Here's my testcase. For some reason this times out when run as part of reftest/crashtest, trying to figure out why.

BTW, I don't get a crash on OS X, I see this in the console though:

malloc: *** error for object 0x123db7c0: double free
*** set a breakpoint in malloc_error_break to debug
This one doesn't timeout.
Attachment #369464 - Attachment is obsolete: true
Attachment #369477 - Flags: superreview+
Attachment #369477 - Flags: review+
Attachment #369477 - Flags: approval1.9.0.9?
Attachment #369464 - Flags: approval1.9.0.9?
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Target Milestone: mozilla1.9.2a1 → mozilla1.9.1
Comment on attachment 369477 [details] [diff] [review]
v1 (with testcase)

Approved for 1.9.0.9, a=dveditz for release-drivers
Attachment #369477 - Flags: approval1.9.0.9? → approval1.9.0.9+
Checked this in on trunk, but without testcase for now.

http://hg.mozilla.org/mozilla-central/rev/6be868e5714c
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Peter: We'd like to take this on 1.9.0.9, which is technically code frozen already. Please check it in as soon as you can. Our builds don't start for 6 days, but we'd like some verification before they start as well. Thanks!
Checked in on 1.9.0.9 and 1.9.1. The bug can be verified with attachment 369469 [details], I'll check in the automated testcase when the bug is opened.
(In reply to comment #10)
> Checked in on 1.9.0.9 and 1.9.1. The bug can be verified with attachment
> 369469 [details], I'll check in the automated testcase when the bug is opened.

Test case doesn't crash Firefox 3.0.7 (or 3.0.8) on OS X or XP when loaded. It and 1.9.0.9 give an error page instead:

Error loading stylesheet: A network error occured loading an XSLT stylesheet:https://bug483444.bugzilla.mozilla.org/attachment.cgi?id=369469&t=yl5JXbb9Uu#stylesheet


1.9.1 gives a similar error:

Error loading stylesheet: An unknown error has occurred (805303f4)https://bug483444.bugzilla.mozilla.org/attachment.cgi?id=369469&t=HEBKYmw2kR#stylesheet
test locally. the redirections used by the pseudo-domains for bugzilla attachments screws with any feature that is limited to same-origin. XSLT stylesheets are one of those.
Ah.

Verified using Windows XP with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.9pre) Gecko/2009040206 GranParadiso/3.0.9pre (.NET CLR 3.5.30729) for 1.9.0.9.
Flags: blocking1.8.1.next? → blocking1.8.1.next+
Group: core-security
pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/10810719ccd5

verified FIXED on builds: 

 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090421 Minefield/3.6a1pre ID:20090421032809

and

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090421 Shiretoko/3.5b4pre ID:20090421030848
Status: RESOLVED → VERIFIED
peter: did the tests get checked in?
I don't think patching this on 1.8 branches would be right. mNext is not an Auto pointer here:

extensions/transformiix/source/xslt/txInstructions.h:    txInstruction* mNext;

dveditz, please check and clear the 1.8.1 flags?
Flags: blocking1.8.1.next?
Flags: blocking1.8.1.next+
Flags: blocking1.8.0.next?
Flags: blocking1.8.0.next-
peterv: ping

dveditz: ping

is there a right way to track getting tests of security-sensitive bugs checked in post-disclosure?  this bug  shows that without one, things fall through the cracks.
As far as I can see the following testcase was checked in:
http://mxr.mozilla.org/mozilla-central/source/content/xslt/crashtests/483444.xml

Do you have more? If so, would be great if you could attach it to the bug so we can check it in as a crashtest.
BTW, I left the in-testsuite? to remind me to check it in to branch.
Testcase checked in on branch.

(In reply to comment #17)
> I don't think patching this on 1.8 branches would be right. mNext is not an
> Auto pointer here:

Yeah, that seems right.
Flags: in-testsuite? → in-testsuite+
Flags: wanted1.8.1.x-
Flags: wanted1.8.1.x+
Flags: blocking1.8.1.next?
Flags: blocking1.8.1.next-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: