Last Comment Bug 483444 - XSLT stylesheet compiler crashes
: XSLT stylesheet compiler crashes
[sg:critical?] double free
: verified1.9.0.9, verified1.9.1
Product: Core
Classification: Components
Component: XSLT (show other bugs)
: Trunk
: All All
P2 critical (vote)
: mozilla1.9.1
Assigned To: Peter Van der Beken [:peterv]
: Andrew Overholt [:overholt]
Depends on:
  Show dependency treegraph
Reported: 2009-03-14 14:07 PDT by Oleg Romashin (:romaxa)
Modified: 2009-05-20 15:42 PDT (History)
17 users (show)
jst: blocking1.9.1+
dveditz: blocking1.9.0.9+
dveditz: wanted1.9.0.x+
dveditz: wanted1.8.1.x-
peterv: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

valgrind output (15.43 KB, text/plain)
2009-03-14 14:17 PDT, Oleg Romashin (:romaxa)
no flags Details
v1 (500 bytes, patch)
2009-03-25 14:32 PDT, Peter Van der Beken [:peterv]
mrbkap: review+
mrbkap: superreview+
Details | Diff | Splinter Review
v1 (with testcase) (1.59 KB, patch)
2009-03-26 02:17 PDT, Peter Van der Beken [:peterv]
peterv: review+
peterv: superreview+
Details | Diff | Splinter Review
Testcase (CRASHES) (532 bytes, application/xml)
2009-03-26 02:48 PDT, Peter Van der Beken [:peterv]
no flags Details
v1 (with testcase) (1.59 KB, patch)
2009-03-26 03:16 PDT, Peter Van der Beken [:peterv]
peterv: review+
peterv: superreview+
dveditz: approval1.9.0.9+
Details | Diff | Splinter Review
1.8.0 version (593 bytes, patch)
2009-04-09 07:11 PDT, Martin Stránský
no flags Details | Diff | Splinter Review

Description User image Oleg Romashin (:romaxa) 2009-03-14 14:07:15 PDT
I don't have external URL for testcase yet, but any firefox 3.0 browser crashes on some specific testcase:

#0  0xb7f1b7f2 in _dl_sysinfo_int80 () from /lib/
#1  0xb7ef9460 in raise () from /lib/i686/cmov/
#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/
#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 "", 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 "", 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/
Comment 1 User image Oleg Romashin (:romaxa) 2009-03-14 14:17:18 PDT
Created attachment 367425 [details]
valgrind output
Comment 2 User image Peter Van der Beken [:peterv] 2009-03-25 14:32:39 PDT
Created attachment 369368 [details] [diff] [review]

mNext is an nsAutoPtr. I'll add a testcase too.
Comment 3 User image Reed Loden [:reed] (use needinfo?) 2009-03-26 02:15:16 PDT has the testcase.
Comment 4 User image Peter Van der Beken [:peterv] 2009-03-26 02:17:59 PDT
Created attachment 369464 [details] [diff] [review]
v1 (with testcase)

Moving reed's approval request.
Comment 5 User image Peter Van der Beken [:peterv] 2009-03-26 02:48:10 PDT
Created attachment 369469 [details]
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
Comment 6 User image Peter Van der Beken [:peterv] 2009-03-26 03:16:49 PDT
Created attachment 369477 [details] [diff] [review]
v1 (with testcase)

This one doesn't timeout.
Comment 7 User image Daniel Veditz [:dveditz] 2009-03-30 14:10:50 PDT
Comment on attachment 369477 [details] [diff] [review]
v1 (with testcase)

Approved for, a=dveditz for release-drivers
Comment 8 User image Peter Van der Beken [:peterv] 2009-03-31 11:14:18 PDT
Checked this in on trunk, but without testcase for now.
Comment 9 User image Samuel Sidler (old account; do not CC) 2009-03-31 11:24:14 PDT
Peter: We'd like to take this on, 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!
Comment 10 User image Peter Van der Beken [:peterv] 2009-03-31 12:29:03 PDT
Checked in on 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.
Comment 11 User image Al Billings [:abillings] 2009-04-02 14:18:11 PDT
(In reply to comment #10)
> Checked in on 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 give an error page instead:

Error loading stylesheet: A network error occured loading an XSLT stylesheet:

1.9.1 gives a similar error:

Error loading stylesheet: An unknown error has occurred (805303f4)
Comment 12 User image Daniel Veditz [:dveditz] 2009-04-02 17:07:02 PDT
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.
Comment 13 User image Al Billings [:abillings] 2009-04-02 17:16:51 PDT

Verified using Windows XP with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/2009040206 GranParadiso/3.0.9pre (.NET CLR 3.5.30729) for
Comment 14 User image Martin Stránský 2009-04-09 07:11:14 PDT
Created attachment 371860 [details] [diff] [review]
1.8.0 version
Comment 15 User image Aakash Desai [:aakashd] 2009-04-23 09:41:59 PDT

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


Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090421 Shiretoko/3.5b4pre ID:20090421030848
Comment 16 User image Marc Bejarano 2009-04-23 14:39:44 PDT
peter: did the tests get checked in?
Comment 17 User image Alexander Sack 2009-04-27 12:21:36 PDT
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?
Comment 18 User image Marc Bejarano 2009-05-13 11:48:03 PDT
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.
Comment 19 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2009-05-13 12:07:44 PDT
As far as I can see the following testcase was checked in:

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.
Comment 20 User image Peter Van der Beken [:peterv] 2009-05-13 12:23:12 PDT
BTW, I left the in-testsuite? to remind me to check it in to branch.
Comment 21 User image Peter Van der Beken [:peterv] 2009-05-20 13:30:56 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.