[Tracking Requested - why for this release]: Top ten volume startup crash in Fx33 betas on Windows only This bug was filed from the Socorro interface and is report bp-d8df37d1-88d0-4e77-9956-82e542140915. ============================================================= Frame Module Signature Source 0 xul.dll mozilla::dom::XULDocument::ExecuteScript(nsIScriptContext*, JS::Handle<JSScript*>) content/xul/document/src/XULDocument.cpp 1 xul.dll mozilla::dom::XULDocument::ExecuteScript(nsXULPrototypeScript*) content/xul/document/src/XULDocument.cpp 2 xul.dll mozilla::dom::XULDocument::OnScriptCompileComplete(JSScript*, tag_nsresult) content/xul/document/src/XULDocument.cpp 3 xul.dll mozilla::dom::XULDocument::OnStreamComplete(nsIStreamLoader*, nsISupports*, tag_nsresult, unsigned int, unsigned char const*) content/xul/document/src/XULDocument.cpp 4 xul.dll nsStreamLoader::OnStopRequest(nsIRequest*, nsISupports*, tag_nsresult) netwerk/base/src/nsStreamLoader.cpp 5 xul.dll nsJARChannel::OnStopRequest(nsIRequest*, nsISupports*, tag_nsresult) modules/libjar/nsJARChannel.cpp 6 xul.dll nsInputStreamPump::OnStateStop() netwerk/base/src/nsInputStreamPump.cpp 7 xul.dll nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) netwerk/base/src/nsInputStreamPump.cpp 8 xul.dll nsInputStreamReadyEvent::Run() xpcom/io/nsStreamUtils.cpp 9 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 10 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp 11 xul.dll nsThread::Shutdown() xpcom/threads/nsThread.cpp 12 xul.dll nsRunnableMethodImpl<tag_nsresult ( nsIUrlClassifierDBServiceWorker::*)(void), void, 1>::Run() obj-firefox/dist/include/nsThreadUtils.h 13 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 14 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp 15 xul.dll nsThread::Shutdown() xpcom/threads/nsThread.cpp 16 xul.dll nsRunnableMethodImpl<tag_nsresult ( nsIUrlClassifierDBServiceWorker::*)(void), void, 1>::Run() obj-firefox/dist/include/nsThreadUtils.h 17 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 18 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp 19 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 20 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 21 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 22 xul.dll nsBaseAppShell::Run() widget/xpwidgets/nsBaseAppShell.cpp 23 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp 24 xul.dll XREMain::XRE_mainRun() toolkit/xre/nsAppRunner.cpp 25 xul.dll XREMain::XRE_main(int, char** const, nsXREAppData const*) toolkit/xre/nsAppRunner.cpp 26 xul.dll XRE_main toolkit/xre/nsAppRunner.cpp 27 firefox.exe do_main browser/app/nsBrowserApp.cpp 28 firefox.exe NS_internal_main(int, char**) browser/app/nsBrowserApp.cpp 29 firefox.exe wmain toolkit/xre/nsWindowsWMain.cpp 30 firefox.exe __tmainCRTStartup f:/dd/vctools/crt_bld/self_x86/crt/src/crtexe.c:552 31 kernel32.dll BaseThreadInitThunk 32 ntdll.dll __RtlUserThreadStart 33 ntdll.dll _RtlUserThreadStart

Looks like a null+offset crash, and probably a regression from Bug 990729

We should probably just NS_ENSURE_TRUE(mCurrentPrototype,...)

Top crash, tracking. Does it impact other versions?

Bill, can you help here? thanks

Do you know how this could happen Bobby? I don't understand how we could execute a script on a XUL document that has no prototype document.

Comment on attachment 8494818 [details] [diff] [review] xul-fix Review of attachment 8494818 [details] [diff] [review]: ----------------------------------------------------------------- I think smaug knows this code much better than I do.

Comment on attachment 8494818 [details] [diff] [review] xul-fix Isn't the crash about mCurrentPrototype being null, not mCurrentScriptProto. mCurrentScriptProto certainly can be null in many cases http://hg.mozilla.org/releases/mozilla-beta/annotate/f4bca655abc9/content/xul/document/src/XULDocument.cpp#l3595 And as far as I see mCurrentPrototype can be null if an overlay fails to load. (I don't quite see what guarantees ExecuteScript is called only with the right prototype document in mCurrentPrototype, but maybe something does that.)

Yeah, I meant to use mCurrentPrototype in my original patch. This one is more conservative. It just uses a null addonId if mCurrentPrototype is null. There's effectively no danger in doing that.

Comment on attachment 8495499 [details] [diff] [review] xul-fix2 Approval Request Comment [Feature/regressing bug #]: bug 990729 [User impact if declined]: nullptr crashes [Describe test coverage new/current, TBPL]: on m-c [Risks and why]: Very low risk. Just avoids the null crash. [String/UUID change made/needed]: None.

https://hg.mozilla.org/releases/mozilla-aurora/rev/31186ed35286 https://hg.mozilla.org/releases/mozilla-beta/rev/b57f0af03f78

Looking in Socorro for crashes over the past 3 days [1], I see some 500 crashes on Firefox 33 Beta 7, but NO crashes on Firefox 33 Beta 8. Nightly and Aurora were not affected and do not show any crashes for recent days. I think it's safe to call this Verified. [1] https://crash-stats.mozilla.com/report/list?product=Firefox&range_unit=days&range_value=3&signature=mozilla%3A%3Adom%3A%3AXULDocument%3A%3AExecuteScript%28nsIScriptContext%2A%2C+JS%3A%3AHandle%3CJSScript%2A%3E%29