Closed Bug 791440 Opened 11 years ago Closed 6 years ago

crash in nsGlobalWindow::SetInitialPrincipalToSubject


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

16 Branch
Windows 7
Not set



Tracking Status
firefox-esr52 --- wontfix
firefox55 --- wontfix
firefox56 --- fixed
firefox57 --- fixed


(Reporter: scoobidiver, Assigned: baku)


(Keywords: crash, regression, testcase)

Crash Data


(5 files)

It first appeared in 16.0b3 and is currently #44 top browser crasher in this build. The regression range is:
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 Address	0xa6
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x06e0, AdapterSubsysID: 00000000, AdapterDriverVersion:
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/
12 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/
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:
So, it looks like the call to CreateAboutBlankContentViewer is failing:

In particular, it must be failing before this callstack completes: 

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.
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)
Summary: crash in nsGlobalWindow::SetInitialPrincipalToSubject → crash in nsGlobalWindow::SetInitialPrincipalToSubject with Helper Bar
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?
(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)

What do we know about Helper Bar? A quick search for it didn't yield any useful results.
(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:
I've contacted them with information about this bug. I'll give them until the end of next week before we go with blocklisting.
The Linkury folks got back to me asking for steps to reproduce. Do we have any?
(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)
     27% (21/77) vs.   2% (1334/57413)
     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)
     18% (14/77) vs.  10% (5549/57413)
      9% (7/77) vs.   1% (707/57413) {F53C93F1-07D5-430c-86D4-C9531B27DFAF}
Summary: crash in nsGlobalWindow::SetInitialPrincipalToSubject with Helper Bar → crash in nsGlobalWindow::SetInitialPrincipalToSubject mainly with Helper Bar
Keywords: qawanted
QA Contact: jbecerra
Summary: crash in nsGlobalWindow::SetInitialPrincipalToSubject mainly with Helper Bar → crash in nsGlobalWindow::SetInitialPrincipalToSubject
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:

Does anyone know a good link from where I could download and install a usable Linkury Smartbar?
According to the developers, you can get it here:
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.
Keywords: qawanted
Crash Signature: [@ nsGlobalWindow::SetInitialPrincipalToSubject()] → [@ nsGlobalWindow::SetInitialPrincipalToSubject()] [@ nsGlobalWindow::SetInitialPrincipalToSubject]
Attached file test_case.html
1) allow pop-ups
2) open test case
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 a couple of tiimes...
Andrew, can you find somebody to look at this crash?  We even have a testcase!
Flags: needinfo?(overholt)
Oh, it's really spiking recently. baku, please investigate.
Flags: needinfo?(overholt) → needinfo?(amarchesini)
Attached patch doc_check.patchSplinter Review
All the rest of that method does check mDoc, except that line.
Assignee: nobody → amarchesini
Flags: needinfo?(amarchesini)
Attachment #8905106 - Flags: review?(kyle)
Attachment #8905106 - Flags: review?(kyle) → review+
Pushed by
nsGlobalWindow::SetInitialPrincipalToSubject should check the existence of mDoc, r=qdot
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Please request Beta/ESR52 approval on this when you get a chance.
Flags: needinfo?(amarchesini)
Comment on attachment 8905106 [details] [diff] [review]

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
Flags: needinfo?(amarchesini)
Attachment #8905106 - Flags: approval-mozilla-esr52?
Attachment #8905106 - Flags: approval-mozilla-beta?
Attached patch esr52Splinter Review
Attached patch m-bSplinter Review
Attachment #8906232 - Attachment description: 64bf8308a282 → m-b
Attachment #8906232 - Attachment is patch: true
Comment on attachment 8905106 [details] [diff] [review]

Fix a crash. Beta56+.
Attachment #8905106 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 8905106 [details] [diff] [review]

old bug, low volume crash, going to leave that out of esr.
Attachment #8905106 - Flags: approval-mozilla-esr52? → approval-mozilla-esr52-
This brought an improvement:

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


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

For up to date results, see:
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.