Closed
Bug 1185593
Opened 9 years ago
Closed 9 years ago
crash in nsXULPrototypeElement::Deserialize(nsIObjectInputStream*, nsXULPrototypeDocument*, nsIURI*, nsTArray<T> const*)
Categories
(Core :: XUL, defect)
Tracking
()
People
(Reporter: alex_mayorga, Assigned: mccr8)
References
Details
(Keywords: crash, topcrash-win)
Crash Data
This bug was filed from the Socorro interface and is report bp-818f0080-1c2d-40f2-b20b-3f9502150719. ============================================================= Top #10 startup crash signature for Nightly, but it is significant on 41 too. https://crash-stats.mozilla.com/report/list?product=Firefox&signature=nsXULPrototypeElement%3A%3ADeserialize%28nsIObjectInputStream%2A%2C+nsXULPrototypeDocument%2A%2C+nsIURI%2A%2C+nsTArray%3CT%3E+const%2A%29 Crashing Thread Frame Module Signature Source 0 xul.dll nsXULPrototypeElement::Deserialize(nsIObjectInputStream*, nsXULPrototypeDocument*, nsIURI*, nsTArray<nsRefPtr<mozilla::dom::NodeInfo> > const*) dom/xul/nsXULElement.cpp 1 xul.dll nsXULPrototypeDocument::Read(nsIObjectInputStream*) dom/xul/nsXULPrototypeDocument.cpp 2 xul.dll nsXULPrototypeCache::GetPrototype(nsIURI*) dom/xul/nsXULPrototypeCache.cpp 3 xul.dll mozilla::dom::XULDocument::LoadOverlayInternal(nsIURI*, bool, bool*, bool*) dom/xul/XULDocument.cpp 4 xul.dll mozilla::dom::XULDocument::ResumeWalk() dom/xul/XULDocument.cpp 5 xul.dll mozilla::dom::XULDocument::OnPrototypeLoadDone(bool) dom/xul/XULDocument.cpp 6 xul.dll mozilla::dom::XULDocument::CachedChromeStreamListener::OnStopRequest(nsIRequest*, nsISupports*, nsresult) dom/xul/XULDocument.cpp 7 xul.dll nsDocumentOpenInfo::OnStopRequest(nsIRequest*, nsISupports*, nsresult) uriloader/base/nsURILoader.cpp 8 xul.dll nsJARChannel::OnStopRequest(nsIRequest*, nsISupports*, nsresult) modules/libjar/nsJARChannel.cpp 9 xul.dll nsInputStreamPump::OnStateStop() netwerk/base/nsInputStreamPump.cpp 10 xul.dll nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) netwerk/base/nsInputStreamPump.cpp 11 xul.dll nsInputStreamReadyEvent::Run() xpcom/io/nsStreamUtils.cpp 12 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 13 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp 14 xul.dll nsThread::Shutdown() xpcom/threads/nsThread.cpp 15 xul.dll mozilla::crashreporter::LSPAnnotationGatherer::Annotate() widget/windows/LSPAnnotator.cpp 16 xul.dll nsRunnableMethodImpl<void ( mozilla::dom::ServiceWorkerRegistrar::*)(void), 1>::Run() xpcom/glue/nsThreadUtils.h 17 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 18 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 19 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 20 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 21 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp 22 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp 23 xul.dll nsAppStartup::Run() toolkit/components/startup/nsAppStartup.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/crtw32/startup/crt0.c:255 31 kernel32.dll BaseThreadInitThunk 32 ntdll.dll __RtlUserThreadStart 33 ntdll.dll _RtlUserThreadStart
This signature dramatically increased in volume in the 20150731030206 build. Here's one of the crashes in case it's different from comment 0: bp-5711ae44-07c4-4426-82b4-41c5b2150731. Based on that build the regression range would be: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=62469b20ec84&tochange=ca53d4297f02 Andrew, perhaps bug 1074416? (And if not, could you suggest another developer? I'm at a loss for owner knowledge in this part of the code)
Flags: needinfo?(continuation)
Assignee | ||
Comment 3•9 years ago
|
||
That doesn't seem too likely. This is in the XUL prototype cache, so it is possible something just mangled the cache and we're reading garbage. The cache itself doesn't seem to have changed recently. q1's suggestion in bug 1188234 seems reasonable, so we can try that.
Component: DOM → XUL
Flags: needinfo?(continuation)
Comment 4•9 years ago
|
||
[Tracking Requested - why for this release]: This is a high volume crash on Nightly (Fx42). Not as much on 41, but present there.
status-firefox41:
--- → affected
tracking-firefox41:
--- → ?
tracking-firefox42:
--- → ?
Keywords: topcrash-win
Assignee | ||
Comment 5•9 years ago
|
||
I'm attempting a fix in bug 1188234, so I can take this for now. I wonder if maybe the recent spike is somehow related to the increase in OOM crashes so we end up with mangled XUL caches or something.
Assignee: nobody → continuation
It doesn't quite line up with the date ranges, but it is an interesting possibility.
Tracked as it is a high volume crash on Nightly and Dev Edition.
Assignee | ||
Comment 9•9 years ago
|
||
It looks like the last Nightly this showed up in was the 8-05 build, which was right before bug 1188234 landed, so I'm going to call this fixed by that. I'll request beta approval so this will get in 41.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 10•9 years ago
|
||
I don't see any crashes in 41 after the 8-11 build, and I don't see any for Aurora.
You need to log in
before you can comment on or make changes to this bug.
Description
•