1225678 - startup crash in nsGlobalWindow::SetDocShell

Status: RESOLVED WORKSFORME

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

Description

[u279076]

This bug was filed from the Socorro interface and is 
report bp-630afc12-4496-4b50-93d0-674f22151116.
=============================================================
0 	xul.dll 	nsGlobalWindow::SetDocShell(nsIDocShell*) 	dom/base/nsGlobalWindow.cpp
Ø 1 	{9a887e1c-4078-4827-9a31-aafc133f05ec}.xpi 	{9a887e1c-4078-4827-9a31-aafc133f05ec}.xpi@0x2a93 	
2 	xul.dll 	nsObserverList::NotifyObservers(nsISupports*, char const*, wchar_t const*) 	xpcom/ds/nsObserverList.cpp
3 	xul.dll 	nsObserverService::NotifyObservers(nsISupports*, char const*, wchar_t const*) 	xpcom/ds/nsObserverService.cpp
4 	xul.dll 	nsContentSink::NotifyDocElementCreated(nsIDocument*) 	dom/base/nsContentSink.cpp
5 	xul.dll 	nsDocElementCreatedNotificationRunner::Run() 	dom/base/nsDocElementCreatedNotificationRunner.h
6 	xul.dll 	nsHTMLDocument::EndUpdate(unsigned int) 	dom/html/nsHTMLDocument.cpp
7 	xul.dll 	nsHtml5DocumentBuilder::EndDocUpdate() 	parser/html/nsHtml5DocumentBuilder.h
8 	xul.dll 	nsHtml5TreeOpExecutor::StartLayout() 	parser/html/nsHtml5TreeOpExecutor.cpp
9 	xul.dll 	nsHtml5TreeOperation::Perform(nsHtml5TreeOpExecutor*, nsIContent**) 	parser/html/nsHtml5TreeOperation.cpp
10 	xul.dll 	nsHtml5TreeOpExecutor::RunFlushLoop() 	parser/html/nsHtml5TreeOpExecutor.cpp
11 	xul.dll 	nsHtml5ExecutorFlusher::Run() 	parser/html/nsHtml5StreamParser.cpp
12 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
13 	xul.dll 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp
14 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc
15 	xul.dll 	nsThreadManager::NewThread(unsigned int, unsigned int, nsIThread**) 	xpcom/threads/nsThreadManager.cpp
16 	xul.dll 	nsAppShell::Run() 	widget/windows/nsAppShell.cpp
17 	xul.dll 	XREMain::XRE_mainRun() 	toolkit/xre/nsAppRunner.cpp
18 	xul.dll 	XREMain::XRE_main(int, char** const, nsXREAppData const*) 	toolkit/xre/nsAppRunner.cpp
19 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp
20 	windows.storage.dll 	FileExplorerTelemetry::DefView_Group::StopActivity() 	
=============================================================
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=nsGlobalWindow%3A%3ASetDocShell

This is a startup crash that appears to be spiking with Firefox Aurora 44.0a2. 10% of the reports correlate to the [e-mail] addon but most the reports have an xpi with different UUIDs in the second frame of the crashing thread.

Hiding the bug for now since all reports show high exploitibility.

Comment 1

[u279076]

[Tracking Requested - why for this release]: nominating to track since this is the #4 topcrash in Aurora.

Comment 2

[u279076]

Based on the data this starts with Firefox 44.0a1 20151028030432:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9a8f2342fb3116d23989087e026448d38a3768c5&tochange=fc706d376f0658e560a59c3dd520437b18e8c4a4

Comment 3

[Andrew Overholt [:overholt]]

baku, khuey: any thoughts here? (I'm starting with you mostly randomly based on blame)

Comment 4

[Andrea Marchesini [:baku]]

It seems that that window is not valid anymore. Could it be that a previous observer deleted the document?

Comment 5

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Why does the stack have a .xpi in it?

Comment 6

[Andrea Marchesini [:baku]]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #5)
> Why does the stack have a .xpi in it?

Looking around it seems that often we see the XPI UUID of the default FF theme.

Comment 7

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Tracked for FF44 since it's a top crash.

Comment 8

[(not currently active) Ted Mielczarek]

This is certainly puzzling! The full path to that file is C:\Users\wawa\AppData\Local\Temp\{9A887E1C-4078-4827-9A31-AAFC133F05EC}.xpi . I noticed it has a version number specified, so it can't be an actual XPI file (or it wouldn't have valid version information). Googling that version number (1.0.5798.16892) only pulled up 5 results, all of which are malware listings:
https://www.reasoncoresecurity.com/plugin.exe-2d6ae36b7b42f66c359d4273c505ddc0e182821d.aspx

Dollars to donuts this is some variant of that malware.

Comment 9

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Andrew, is there any chance we might get a dev to investigate this some more? On 44.0b, this is data for last 28 days:

Product 	Version 	Percentage 	Number Of Crashes
Firefox 	44.0a2 	         86.05% 	870
Firefox 	44.0b1 	         8.31% 	        84

Comment 10

[Andrew Overholt [:overholt]]

Given comment 8 I'm not sure who'd be best to look into this more. Benjamin, in the past I would have guessed dmajor; any suggestions?

Comment 11

[Andrea Marchesini [:baku]]

(In reply to Ted Mielczarek [:ted.mielczarek] from comment #8)
> This is certainly puzzling! The full path to that file is
> C:\Users\wawa\AppData\Local\Temp\{9A887E1C-4078-4827-9A31-AAFC133F05EC}.xpi

Wondering if we can have this XPI.

Comment 12

[(not currently active) Ted Mielczarek]

FWIW, it's not really an XPI, it's a DLL file disguised as an XPI. Apparently the malware that distributes this file also sometimes calls it "plugin.exe" or "plugin-container.exe". The page I linked in comment 8 says the software is called "Nugget Find", but I could not find anywhere to download an installer. Various pages claim that it's installed as a drive-by packaged in other software's installers.

Comment 13

[Benjamin Smedberg]

I don't see why this bug needs to be marked s-s.

If this weren't a topcrash, I'd recommend WONTFIX.

As a topcrash, we would take a DLL blocklist or an addon blocklist fix if that could be effective. If this is a random DLL name, though, we don't have enough for a blocklist.

Best bet might be to reach out and try to get this added to Windows Defender; I think Kev may have contacts for that. Mostly useful if there is an actual sample of the malware, though.

Comment 14

[Andrew Overholt [:overholt]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #13)
> Best bet might be to reach out and try to get this added to Windows
> Defender; I think Kev may have contacts for that. Mostly useful if there is
> an actual sample of the malware, though.

Kev, what say you?

Comment 15

[Andrew Overholt [:overholt]]

This doesn't look like a top crasher anymore (but I could be mis-reading crash-stats). Ritu, should we continue to track it?

Comment 16

[u279076]

Attachment: Crash Curve Visualization

Actually, I think this can be closed. Volume has basically dropped apart from a handful of crashes (3 in Beta over the last week). Attached is a visualization showing the curve for this crash over the last six months.

Comment 17

[u279076]

I'm going to go ahead and close this as per my previous comment. Feel free to reopen if you think this bug needs further action.

Comment 18

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to Andrew Overholt [:overholt] from comment #15)
> This doesn't look like a top crasher anymore (but I could be mis-reading
> crash-stats). Ritu, should we continue to track it?

Hi Andrew, yup, this crash is basically very low volume now. We hit it only 11 times in the past week and not on late 44 beta builds at all. With that I am willing to mark this as fixed.