335849 - [FIX]Yahoo Mail Beta crashes 1.8.1 branch/linux with a null principal [@ nsScriptSecurityManager::CheckSameOriginPrincipalInternal]

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[Doron Rosenberg (IBM)]

#
#0  0x00e2a402 in __kernel_vsyscall ()
#
#1  0x0053e7f6 in __nanosleep_nocancel () from /lib/libc.so.6
#
#2  0x0053e603 in sleep () from /lib/libc.so.6
#
#3  0x0805fde3 in ah_crap_handler (signum=11) at nsSigHandlers.cpp:132
#
#4  0x08060bdb in nsProfileLock::FatalSignalHandler (signo=11) at nsProfileLock.cpp:210
#
#5  <signal handler called>
#
#6  0x05736555 in nsScriptSecurityManager::CheckSameOriginPrincipalInternal (this=0x902a548, aSubject=0xa425918, aObject=0x0, aIsCheckConnect=0) at /home/doron/mozbuilds/firefox-1.8/mozilla/caps/src/nsScriptSecurityManager.cpp:855
#
#7  0x057369de in nsScriptSecurityManager::CheckSameOriginPrincipal (this=0x902a548, aSourcePrincipal=0xa425918, aTargetPrincipal=0x0) at /home/doron/mozbuilds/firefox-1.8/mozilla/caps/src/nsScriptSecurityManager.cpp:601
#
#8  0x02e9a478 in nsContentUtils::CheckSameOrigin (aTrustedNode=0xa425780, aUnTrustedNode=0xb30ef184) at /home/doron/mozbuilds/firefox-1.8/mozilla/content/base/src/nsContentUtils.cpp:642
#
#9  0x02ed0c1d in nsGenericElement::doReplaceOrInsertBefore (aReplace=1, aNewChild=0xb30ef184, aRefChild=0xa4251c4, aParent=0x0, aDocument=0xa425700, aChildArray=@0xa425800, aReturn=0xbf968730) at /home/doron/mozbuilds/firefox-1.8/mozilla/content/base/src/nsGenericElement.cpp:3342
#
#10 0x02ea811f in nsDocument::ReplaceChild (this=0xa425700, aNewChild=0xb30ef184, aOldChild=0xa4251c4, aReturn=0xbf968730) at /home/doron/mozbuilds/firefox-1.8/mozilla/content/base/src/nsDocument.cpp:3467
#
#11 0x001ba1f5 in XPTC_InvokeByIndex () at /home/doron/mozbuilds/firefox-1.8/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp:48
#
#12 0x003056ab in XPCWrappedNative::CallMethod (ccx=@0xbf96883c, mode=XPCWrappedNative::CALL_METHOD) at /home/doron/mozbuilds/firefox-1.8/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2152
#
#13 0x0030c519 in XPC_WN_CallMethod (cx=0x95bf3b0, obj=0x9ef8c70, argc=2, argv=0x9cbbfd0, vp=0xbf968974) at /home/doron/mozbuilds/firefox-1.8/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1445
#
#14 0x00ed5286 in js_Invoke (cx=0x95bf3b0, argc=2, flags=0) at /home/doron/mozbuilds/firefox-1.8/mozilla/js/src/jsinterp.c:1177
#
#15 0x00ee0970 in js_Interpret (cx=0x95bf3b0, pc=Variable "pc" is not available.
#
) at /home/doron/mozbuilds/firefox-1.8/mozilla/js/src/jsinterp.c:3572
#
#16 0x00ed5a76 in js_Execute (cx=0x95bf3b0, chain=0x92c9460, script=0x9d6ed58, down=0x0, flags=0, result=0xbf968d54) at /home/doron/mozbuilds/firefox-1.8/mozilla/js/src/jsinterp.c:1423
#
#17 0x00eadbc9 in JS_EvaluateUCScriptForPrincipals (cx=0x95bf3b0, obj=0x92c9460, principals=0x976f534, chars=0x9e753c8, length=4, filename=0xa4b58a0 "http://us.js2.yimg.com/us.js.yimg.com/lib/pim/r/dclient/js/fb138ca0aef24d51954db355a1149545_1.js", lineno=369, rval=0xbf968d54) at /home/doron/mozbuilds/firefox-1.8/mozilla/js/src/jsapi.c:4123
#
#18 0x03000b8e in nsJSContext::EvaluateString (this=0x95bf300, aScript=@0xbf968e98, aScopeObject=0x92c9460, aPrincipal=0x976f530, aURL=0xa4b58a0 "http://us.js2.yimg.com/us.js.yimg.com/lib/pim/r/dclient/js/fb138ca0aef24d51954db355a1149545_1.js", aLineNo=369, aVersion=0xf3516d "default", aRetValue=0x0, aIsUndefined=0xbf968e88) at /home/doron/mozbuilds/firefox-1.8/mozilla/dom/src/base/nsJSEnvironment.cpp:1061
#
#19 0x0301bb04 in nsGlobalWindow::RunTimeout (this=0x980a3f8, aTimeout=0xa4b5850) at /home/doron/mozbuilds/firefox-1.8/mozilla/dom/src/base/nsGlobalWindow.cpp:6305
#
#20 0x0301bf57 in nsGlobalWindow::TimerCallback (aTimer=0xa4b5908, aClosure=0xa4b5850) at /home/doron/mozbuilds/firefox-1.8/mozilla/dom/src/base/nsGlobalWindow.cpp:6679
#
#21 0x0019d5ca in nsTimerImpl::Fire (this=0xa4b5908) at /home/doron/mozbuilds/firefox-1.8/mozilla/xpcom/threads/nsTimerImpl.cpp:394
#
#22 0x0019d7ac in handleTimerEvent (event=0xb2c747d0) at /home/doron/mozbuilds/firefox-1.8/mozilla/xpcom/threads/nsTimerImpl.cpp:459
#
#23 0x00197091 in PL_HandleEvent (self=0xb2c747d0) at /home/doron/mozbuilds/firefox-1.8/mozilla/xpcom/threads/plevent.c:688
#
#24 0x00196f66 in PL_ProcessPendingEvents (self=0x8fadd00) at /home/doron/mozbuilds/firefox-1.8/mozilla/xpcom/threads/plevent.c:623
#
#25 0x00199595 in nsEventQueueImpl::ProcessPendingEvents (this=0x8fb84e0) at /home/doron/mozbuilds/firefox-1.8/mozilla/xpcom/threads/nsEventQueue.cpp:417
#
#26 0x00f58576 in event_processor_callback (source=0x92fa5f0, condition=G_IO_IN, data=0x8fb84e0) at /home/doron/mozbuilds/firefox-1.8/mozilla/widget/src/gtk2/nsAppShell.cpp:67
#
#27 0x002564fc in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#
#28 0x002304ce in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#
#29 0x002334d6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#
#30 0x002337c3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#
#31 0x00a57a46 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#
#32 0x00f58db1 in nsAppShell::Run (this=0x9029388) at /home/doron/mozbuilds/firefox-1.8/mozilla/widget/src/gtk2/nsAppShell.cpp:139
#
#33 0x05cc54c6 in nsAppStartup::Run (this=0x9029340) at /home/doron/mozbuilds/firefox-1.8/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:150
#
#34 0x08050ddf in XRE_main (argc=2, argv=0xbf969474, aAppData=0x8065020) at /home/doron/mozbuilds/firefox-1.8/mozilla/toolkit/xre/nsAppRunner.cpp:2376
#
#35 0x0804b3af in main (argc=2, argv=0xbf969474) at /home/doron/mozbuilds/firefox-1.8/mozilla/browser/app/nsBrowserApp.cpp:61

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Does this help?

Note that if it does it'll probably give you security exceptions instead of crashing... ;)

Comment 2

[Doron Rosenberg (IBM)]

Yup, no crash, but obviously the web app is broke :)

Comment 3

[Doron Rosenberg (IBM)]

Seems that mDocumentURI on the nsIDocument is null.  

From venkman, XMLDocument has a baseURI and a documentURI, both being:
"http://us.f389.mail.yahoo.com/dc/launch?action=welcome&..."

NodeType is 9 (DOCUMENT_NODE).

From what I can tell, this code generates it:
new DOMParser()).parseFromString(this.innerHTML,"text/xml")

Comment 4

[Boris Zbarsky [:bzbarsky]]

Er... ParseFromString() should be guaranteeing a URI (falling back on about:blank if needed). Can you trace in there to see what's going on?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 220159 [details] [diff] [review]
Does this help?

I think we want this null-check anyway.

Comment 6

[Doron Rosenberg (IBM)]

I'll debug this more monday, I have a windows 1.8 branch debug build running over the weekend so hopefully it'll be easier to debug then :)

Comment 7

[Doron Rosenberg (IBM)]

I tried today but couldn't find who is creating this evil document.  I debugged xmlhttp and parseFromString, and each created document seemed to be fine.

They are using XSLT, not sure how to debug XSLT (they create some 30 documents).

Comment 8

[Doron Rosenberg (IBM)]

Not sure if this is usefull, but I just caught nsDocument::ResetToURI get a null aUri passed in, with xslt in the stack.  Since I am clueless about most of this, is that a bad thing?

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

That sounds bad yes. I believe we have a bug on that actually, though I can't find it right now.

Comment 10

[Doron Rosenberg (IBM)]

(In reply to comment #9)
> That sounds bad yes. I believe we have a bug on that actually, though I can't
> find it right now.
> 

Forgot to mention, the reason the uri is null is that XSLT has a null channel in the error case.

Comment 11

[Boris Zbarsky [:bzbarsky]]

doron, thanks for hunting that down!  Sounds like bug 323554 to me.  So the null-check really is the right thing to do here.

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Could you please post or attach a short stack that include line numbers.

Comment 13

[Doron Rosenberg (IBM)]

Attachment: xslt stack

Comment 14

[Johnny Stenback (:jst)]

Comment on attachment 220159 [details] [diff] [review]
Does this help?

r+sr+a=jst

Comment 15

[Boris Zbarsky [:bzbarsky]]

Fixed on 1.8 branch.  Doron, do you know whether we need this on 1.8.0 as well?

Comment 16

[Doron Rosenberg (IBM)]

(In reply to comment #15)
> Fixed on 1.8 branch.  Doron, do you know whether we need this on 1.8.0 as well?
> 

Nope, Firefox 1.5.0.3 doesn't crash.