791440 - crash in nsGlobalWindow::SetInitialPrincipalToSubject

Status: RESOLVED FIXED

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

Description

[Scoobidiver (away)]

It first appeared in 16.0b3 and is currently #44 top browser crasher in this build. The regression range is:
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=cad589192f3c&tochange=de3f06a549de
It's likely a regression from bug 774633.

Signature 	nsGlobalWindow::SetInitialPrincipalToSubject() More Reports Search
UUID	378c2d1a-613c-4df3-a31b-9b3232120915
Date Processed	2012-09-15 06:53:19
Uptime	2116
Last Crash	8.8 weeks before submission
Install Age	4.2 hours since version was first installed.
Install Time	2012-09-15 02:38:12
Product	Firefox
Version	16.0
Build ID	20120911232325
Release Channel	beta
OS	Windows NT
OS Version	6.1.7600
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 23 stepping 6
Crash Reason	EXCEPTION_ACCESS_VIOLATION_WRITE
Crash Address	0xa6
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x06e0, AdapterSubsysID: 00000000, AdapterDriverVersion: 8.17.12.6658
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ 
EMCheckCompatibility	True
Adapter Vendor ID	0x10de
Adapter Device ID	0x06e0
Total Virtual Memory	2147352576
Available Virtual Memory	1174827008
System Memory Use Percentage	40
Available Page File	5004394496
Available Physical Memory	1919893504

Frame 	Module 	Signature 	Source
0 	xul.dll 	nsGlobalWindow::SetInitialPrincipalToSubject 	dom/base/nsGlobalWindow.cpp:1544
1 	xul.dll 	nsAppShellService::RegisterTopLevelWindow 	xpfe/appshell/src/nsAppShellService.cpp:458
2 	xul.dll 	nsAppShellService::CreateTopLevelWindow 	xpfe/appshell/src/nsAppShellService.cpp:152
3 	xul.dll 	nsAppStartup::CreateChromeWindow2 	toolkit/components/startup/nsAppStartup.cpp:623
4 	xul.dll 	nsWindowWatcher::OpenWindowJSInternal 	embedding/components/windowwatcher/src/nsWindowWatcher.cpp:706
5 	xul.dll 	nsWindowWatcher::OpenWindow 	embedding/components/windowwatcher/src/nsWindowWatcher.cpp:381
6 	xul.dll 	nsAlertsService::ShowAlertNotification 	toolkit/components/alerts/nsAlertsService.cpp:179
7 	xul.dll 	nsDownload::SetState 	toolkit/components/downloads/nsDownloadManager.cpp:2271
8 	xul.dll 	nsDownloadScanner::Scan::Run 	toolkit/components/downloads/nsDownloadScanner.cpp:416
9 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:624
10 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:82
11 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:201
12 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:175
13 	xul.dll 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:163
14 	xul.dll 	nsAppShell::Run 	widget/windows/nsAppShell.cpp:232
15 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:257
16 	xul.dll 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3794
17 	xul.dll 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3871
18 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3947

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsGlobalWindow%3A%3ASetInitialPrincipalToSubject%28%29

Comment 1

[Bobby Holley (:bholley)]

So, it looks like the call to CreateAboutBlankContentViewer is failing:

http://hg.mozilla.org/releases/mozilla-beta/annotate/de3f06a549de/dom/base/nsGlobalWindow.cpp#l1543

In particular, it must be failing before this callstack completes: 
nsGlobalWindow::SetNewDocument
nsDocumentViewer::InitInternal
nsDocumentViewer::Init
nsDocShell::SetupNewViewer
nsDocShell::CreateAboutBlankContentViewer

which sets mDoc to the relevant about:blank document.

We _could_ check for this, return an NS_ERROR_FAILURE, and bubble it all the way up. But we'd have to add error handling to a number of ancestor callers before getting anywhere that could handle the failure.

As such, I'd prefer if we could reproduce the crash (or correlate it with an addon) and figure out what's going wrong.

Comment 2

[Scoobidiver (away)]

It's correlated to Helper Bar (installed without the permission of users):
  nsGlobalWindow::SetInitialPrincipalToSubject()|EXCEPTION_ACCESS_VIOLATION_WRITE (28 crashes)
    100% (28/28) vs.   1% (427/54486) [e-mail]

Comment 3

[Bobby Holley (:bholley)]

Ok, so clearly they're messing with the docshell somehow and causing it to fail to create about:blank documents. Jorge, What's our next step here? Developer outreach?

Comment 4

[Jorge Villalobos [:jorgev] (he/him)]

(In reply to Scoobidiver from comment #2)
> It's correlated to Helper Bar (installed without the permission of users):
>  
> nsGlobalWindow::
> SetInitialPrincipalToSubject()|EXCEPTION_ACCESS_VIOLATION_WRITE (28 crashes)
>     100% (28/28) vs.   1% (427/54486) [e-mail]

What do we know about Helper Bar? A quick search for it didn't yield any useful results.

Comment 5

[Scoobidiver (away)]

(In reply to Jorge Villalobos [:jorgev] from comment #4)
> What do we know about Helper Bar? A quick search for it didn't yield any
> useful results.
It seems to be Linkury's SmartBar: http://www.threatexpert.com/report.aspx?md5=aa448be2db215b61b17b8537f0c11be4

Comment 6

[Jorge Villalobos [:jorgev] (he/him)]

I've contacted them with information about this bug. I'll give them until the end of next week before we go with blocklisting.

Comment 7

[Jorge Villalobos [:jorgev] (he/him)]

The Linkury folks got back to me asking for steps to reproduce. Do we have any?

Comment 8

[Scoobidiver (away)]

(In reply to Jorge Villalobos [:jorgev] from comment #7)
> The Linkury folks got back to me asking for steps to reproduce. Do we have
> any?
There are no comments in crash reports.

It seems now correlated to other add-ons:
     94% (72/77) vs.   1% (401/57413) [e-mail]
     27% (21/77) vs.   2% (1334/57413) [e-mail]
     27% (21/77) vs.   3% (1574/57413) {EB9394A3-4AD6-4918-9537-31A1FD8E8EDF}
     16% (12/77) vs.   5% (2640/57413) avg@toolbar
     16% (12/77) vs.   5% (2657/57413) [e-mail]
     18% (14/77) vs.  10% (5549/57413) [e-mail]
      9% (7/77) vs.   1% (707/57413) {F53C93F1-07D5-430c-86D4-C9531B27DFAF}

Comment 9

[Simona Badau, Desktop QA, PTO 22-30June]

I could not install the Linkury SmartBar when trying to reproduce the issue, all I got while install it was a virus warning (Mixidj_intl.exe).

I downloaded the Linkury SmartBar from:
http://download.cnet.com/Linkury-SmartBar/3000-2378_4-75415460.html

Does anyone know a good link from where I could download and install a usable Linkury Smartbar?

Comment 10

[Jorge Villalobos [:jorgev] (he/him)]

According to the developers, you can get it here: http://www.linkury.com/index-6_solutions_b.html

Comment 11

[Simona Badau, Desktop QA, PTO 22-30June]

Thanks Jorge!

Mozilla/5.0 (Windows NT 6.1; rv:26.0) Gecko/20100101 Firefox/26.0
Build ID: 20131014004003

I could not reproduce the crash while browsing (sent/read e-mails, played games and videos, navigated to different pages in several tabs, etc) on the latest Aurora 26.0a2 with the following add-ons enabled:
- Linkury Smartbar 1.1
- Funmnoods New Tab 9.5.3
- Babylon toolbar 1.5.0
(I could not find the Blabbers and DealPly add-ons for Firefox - all I found required Chrome as their browser).

I'm removing the qawanted keyword since QA could not reproduce the crash locally. Please re-add it if anything else is needed from the QA side.

Comment 12

[Tyson Smith [:tsmith]]

Attachment: test_case.html

STR:
1) allow pop-ups
2) open test case

Comment 13

[Tyson Smith [:tsmith]]

Attachment: asan_log.txt

Comment 14

[[:philipp]]

this crash signature is also spiking up in the last couple of days - "WebGL+" seems to be always active during those crashes, users of es builds seem to be affected inproportionally often and url correlations point to shink.in a couple of tiimes...

Comment 15

[Nathan Froyd [:froydnj]]

Andrew, can you find somebody to look at this crash?  We even have a testcase!

Comment 16

[Andrew Overholt [:overholt]]

Oh, it's really spiking recently. baku, please investigate.

Comment 17

[Andrea Marchesini [:baku]]

Attachment: doc_check.patch

All the rest of that method does check mDoc, except that line.

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/64bf8308a282
nsGlobalWindow::SetInitialPrincipalToSubject should check the existence of mDoc, r=qdot

Comment 19

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/64bf8308a282

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Please request Beta/ESR52 approval on this when you get a chance.

Comment 21

[Andrea Marchesini [:baku]]

Comment on attachment 8905106 [details] [diff] [review]
doc_check.patch

Approval Request Comment
[Feature/Bug causing the regression]: bug 774633
[User impact if declined]: a crash can occur in same rare conditions
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: hard to verify
[Needs manual test from QE? If yes, steps to reproduce]: n/a 
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: the fix is just a null check.
[String changes made/needed]: none

[Approval Request Comment]
Fix Landed on Version: 57

Comment 22

[Andrea Marchesini [:baku]]

Attachment: esr52

Comment 23

[Andrea Marchesini [:baku]]

Attachment: m-b

Comment 24

[Gerry Chang [:gchang]]

Comment on attachment 8905106 [details] [diff] [review]
doc_check.patch

Fix a crash. Beta56+.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/d3d0e187d53d

Comment 26

[Julien Cristau [:jcristau]]

Comment on attachment 8905106 [details] [diff] [review]
doc_check.patch

old bug, low volume crash, going to leave that out of esr.

Comment 27

[Ionuț Goldan [:igoldan]]

This brought an improvement:

== Change summary for alert #9589 (as of September 21 2017 08:41 UTC) ==

Improvements:

  3%  tpaint summary windows7-32 opt e10s     276.47 -> 269.50

For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=9589