Closed Bug 840901 Opened 11 years ago Closed 11 years ago

crash in nsDocLoader::DoFireOnStateChange with Whitesky's ID Vault (bundled with HP computers?)

Categories

(Firefox :: Extension Compatibility, defect)

19 Branch
x86
Windows 8
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
firefox19 - ---
firefox20 + fixed
firefox21 + fixed
firefox22 --- fixed

People

(Reporter: scoobidiver, Unassigned)

Details

(4 keywords, Whiteboard: [Win8][fixed in Whitesky's ID Vault 1.13.327.1])

Crash Data

It's #5 top crasher in 18.0.2 for Windows 8 only.

It's correlated to CGPS Extension (ID Vault product from Whitesky - see http://www.idvault.com/):
     96% (47/49) vs.   0% (542/137733) idvaultaddin@whitesky (CGPS Extension)
          0% (0/49) vs.   0% (1/137733) 1.0
          0% (0/49) vs.   0% (1/137733) 1.12.1127.2
          0% (0/49) vs.   0% (433/137733) 1.13.111.1
         96% (47/49) vs.   0% (107/137733) 1.13.111.2

That product likely comes bundled in some brand new computers (HP?).

Signature 	nsDocLoader::DoFireOnStateChange(nsIWebProgress* const, nsIRequest* const, int&, tag_nsresult) More Reports Search
UUID	dace5c09-e5e0-45fa-b447-0b6ab2130213
Date Processed	2013-02-13 07:49:38
Uptime	132
Last Crash	2.2 minutes before submission
Install Age	1.0 weeks since version was first installed.
Install Time	2013-02-06 02:09:38
Product	Firefox
Version	18.0.2
Build ID	20130201065344
Release Channel	release
OS	Windows NT
OS Version	6.2.9200
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 58 stepping 9
Crash Reason	EXCEPTION_ACCESS_VIOLATION_EXEC
Crash Address	0xffffffffffffb991
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x0fc6, AdapterSubsysID: 00000000, AdapterDriverVersion: 9.18.13.1090
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ WebGL? EGL? EGL+ GL Context? GL Context+ WebGL+ 
Processor Notes 	sp-processor09.phx1.mozilla.com_434:2008
EMCheckCompatibility	True
Adapter Vendor ID	0x10de
Adapter Device ID	0x0fc6
Total Virtual Memory	4294836224
Available Virtual Memory	3403517952
System Memory Use Percentage	17
Available Page File	16058220544
Available Physical Memory	14175633408

Frame 	Module 	Signature 	Source
0 		@0xffffb991 	
1 		@0x8d5d540 	
2 		@0xefc0fc1 	
3 		@0x87f84db 	
4 		@0x8d5f334 	
5 		@0x8d5f16c 	
6 		@0x87f83f8 	
7 	xul.dll 	nsDocLoader::DoFireOnStateChange 	uriloader/base/nsDocLoader.cpp:1351
8 	xul.dll 	nsDocLoader::doStopDocumentLoad 	uriloader/base/nsDocLoader.cpp:942
9 	xul.dll 	nsDocLoader::DocLoaderIsEmpty 	uriloader/base/nsDocLoader.cpp:820
10 	xul.dll 	nsDocLoader::OnStopRequest 	uriloader/base/nsDocLoader.cpp:704
11 	xul.dll 	nsLoadGroup::RemoveRequest 	netwerk/base/src/nsLoadGroup.cpp:698
12 	xul.dll 	nsLoadGroup::QueryInterface 	netwerk/base/src/nsLoadGroup.cpp:177
13 	xul.dll 	nsDocument::UnblockOnload 	content/base/src/nsDocument.cpp:7329
14 	xul.dll 	nsRunnable::Release 	obj-firefox/xpcom/build/nsThreadUtils.cpp:30
15 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:626
16 	xul.dll 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:82
17 	xul.dll 	MessageLoop::RunHandler 	ipc/chromium/src/base/message_loop.cc:208
18 	xul.dll 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:182
19 	xul.dll 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:163
20 	xul.dll 	nsAppShell::Run 	widget/windows/nsAppShell.cpp:232
21 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:290
22 	xul.dll 	XREMain::XRE_mainRun 	toolkit/xre/nsAppRunner.cpp:3794
23 	xul.dll 	XREMain::XRE_main 	toolkit/xre/nsAppRunner.cpp:3860
24 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3935
25 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:105

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsDocLoader%3A%3ADoFireOnStateChange%28nsIWebProgress*+const%2C+nsIRequest*+const%2C+int%26%2C+tag_nsresult%29
I just sent a message to Whitesky using their online form.
Let's try to reproduce.
Ioana, can you please have someone on your team attempt to reproduce this. Whitesky ID Vault is available here: http://www.idvault.com/
QA Contact: ioana.budnar
ID Vault Extension is compatible by default only with FF 5.0.
I had to manually change the c:\ProgramData\White Sky, Inc\ID Vault\XPCOM\install.rdf to be compatible with FF 18.0.2.
As far as I can see in the crashes comments, users are getting crashes on facebook, webmail, youtube, skype.com, multiple tabs, multiple windows.
None of the above crashed my Firefox, Win 8 x86 today.
As Paul pointed out, ID Vault is not compatible with Firefox 6 or later. The only way I've been able to get it to enable the add-on is by forcing compatibility checks off. Even then, it's still never used. As I understand it, it's supposed to ask me if it wants to protect my accounts when I go to a website that requires me to log in. I've tried several websites (gmail, facebook, yahoo mail, hotmail, amazon, youtube, my bank, my investment management company) none of which trigger ID Vault to activate.

I fail to see how anyone using a current version of Firefox would be able to make any use of this product, let alone crash.

Can someone please advise us on what more we could try?
QA Contact: ioana.budnar → paul.silaghi
What is the ID and version of the ID Vault extension you've installed?
Flags: needinfo?(anthony.s.hughes)
<em:id>idvaultaddin@whitesky</em:id>
<em:name>IDVault Extension</em:name>
<em:version>1.0</em:version>
Flags: needinfo?(anthony.s.hughes)
(In reply to Paul Silaghi [QA] from comment #7)
> <em:version>1.0</em:version>
The crashing version is 1.13.111.2. It may come bundled with Constant Guard Protection Suite (http://xfinity.comcast.net/constantguard/Products/CGPS/) in brand new HP computers.
No longer a top Win8 crasher post-release. Untracking.
(In reply to Scoobidiver from comment #8)
> (In reply to Paul Silaghi [QA] from comment #7)
> > <em:version>1.0</em:version>
> The crashing version is 1.13.111.2. It may come bundled with Constant Guard
> Protection Suite (http://xfinity.comcast.net/constantguard/Products/CGPS/)
> in brand new HP computers.

Unfortunately, downloading this product requires a Comcast XFinity account. Given this is no longer tracked I'm dropping qawanted. There are far more serious bugs that need our attention right now.

That said, if someone reading this is or knows a Comcast customer, please help by testing the above linked product in Firefox 19.

Thank you
Keywords: qawanted
(In reply to Alex Keybl [:akeybl] from comment #9)
> No longer a top Win8 crasher post-release. Untracking.
I disagree. Without bug 830531, it's still #5 top crasher in 19.0.
(In reply to Scoobidiver from comment #11)
> (In reply to Alex Keybl [:akeybl] from comment #9)
> > No longer a top Win8 crasher post-release. Untracking.
> I disagree. Without bug 830531, it's still #5 top crasher in 19.0.

It's 0.2% of all Win8 crashes and #117 on the overall topcrash list, so I don't even see it as any cause of concern for 19, much less for 20, where it's not present at all (3 crashes overall on 20.0b1 so far don't count as anything at all to me).
We much value your input but things should only be nominated for tracking if we believe they would significantly impact our ability to release this version, which I don't think would be the case at all here (even more so because this is no new problem and things that have been happening for a few releases already are not worth tracking for a specific release).
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #12)
> It's 0.2% of all Win8 crashes and #117 on the overall topcrash list, so I
> don't even see it as any cause of concern for 19, much less for 20, where
> it's not present at all (3 crashes overall on 20.0b1 so far don't count as
> anything at all to me).
Bug 830531 is fixed in 20.0 at least in Beta 1 so it will be #5 top crasher for Windows 8 in this version when it's released. #1 top crasher on Mac is #219 browser crasher and accounts for 0.03% of all crashes. Should we stop asking for tracking top Mac and Linux crashes and focus only on Windows ones?

> even more so because this is no new problem and things that have been happening for a
> few releases already are not worth tracking for a specific release
We stop tracking long standing issues that have been investigated for a while when there's no found solution, but new discovered issues should be tracked when a bug is filed. In addition, version 18.0 when those brand new HP computers were released is not so old.
(In reply to Scoobidiver from comment #13)
> > even more so because this is no new problem and things that have been happening for a
> > few releases already are not worth tracking for a specific release
> We stop tracking long standing issues that have been investigated for a
> while when there's no found solution, but new discovered issues should be
> tracked when a bug is filed. In addition, version 18.0 when those brand new
> HP computers were released is not so old.

This is true, but at some point we make the call that the impacted user population is so small that engineering's time is better spent on other release issues or new features.
It's #3 top crasher in 19.0.2 for Windows 8 only so that qualifies it for the topcrash keyword according to https://wiki.mozilla.org/CrashKill/Topcrash

There was an extension update but as crashy as before:
  nsDocLoader::DoFireOnStateChange(nsIWebProgress* const, nsIRequest* const, int&, tag_nsresult)|EXCEPTION_ACCESS_VIOLATION_EXEC (97 crashes)
    100% (97/97) vs.   0% (551/139851) idvaultaddin@whitesky
         78% (76/97) vs.   0% (176/139851) 1.13.219.2
         22% (21/97) vs.   0% (59/139851) 1.13.220.4

I found another download link that doesn't require registration: http://download.cnet.com/ID-Vault/3000-2092_4-10911643.html
Keywords: topcrash
(In reply to Alex Keybl [:akeybl] from comment #14)
> This is true, but at some point we make the call that the impacted user
> population is so small that engineering's time is better spent on other
> release issues or new features.
It's #1 top browser crasher on Windows 8 and accounts for 12.3% of browser crashes on Windows 8. The Windows 8 population won't stop to increase so it's worth the QA (and maybe later engineering) team's investment.
We'll see if we can find somebody at Whitesky to take a look given rising/high crash volume here.

Given current infra, we can't block this add-on only for Win8. And we still haven't found the latest versions of the add-on for reproducing. So our only feasible option is really to keep attempting outreach (until the volume is so high that we are forced to block the add-on).
Whitesky has let us know that they'll be resolving on their end shortly, now that they've been able to reproduce.
Crash Signature: [@ nsDocLoader::DoFireOnStateChange(nsIWebProgress* const, nsIRequest* const, int&, tag_nsresult)] → [@ nsDocLoader::DoFireOnStateChange(nsIWebProgress* const, nsIRequest* const, int&, tag_nsresult)] [@ @0x0 | nsDocLoader::DoFireOnStateChange(nsIWebProgress* const, nsIRequest* const, int&, tag_nsresult) ]
This crash signature is dropping, looks like it's been resolved on Whitesky's end.
Keywords: thirdparty
(In reply to lsblakk@mozilla.com from comment #19)
> This crash signature is dropping
That's not what I see in https://crash-stats.mozilla.com/products/Firefox/versions/19.0.2 and https://crash-analysis.mozilla.com/rkaiser/2013-03-24/2013-03-24.firefox.19.0.2.win8.topcrash.html

> looks like it's been resolved on Whitesky's end.
The only way to confirm is to have bug 836671 fixed.
Component: Document Navigation → Extension Compatibility
Product: Core → Firefox
Version: Trunk → 19 Branch
Whitesky shipped a new version on April 1 that should fix this.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #21)
> Whitesky shipped a new version on April 1 that should fix this.
It seems so based on correlations in 19.0.2 (not enough crashes in 20.0):
  nsDocLoader::DoFireOnStateChange(nsIWebProgress* const, nsIRequest* const, int&, tag_nsresult)|EXCEPTION_ACCESS_VIOLATION_READ (18 crashes)
     72% (13/18) vs.   0% (322/121327) idvaultaddin@whitesky
         22% (4/18) vs.   0% (8/121327) 1.13.219.2
         50% (9/18) vs.   0% (20/121327) 1.13.220.4
          0% (0/18) vs.   0% (56/121327) 1.13.327.1
  nsDocLoader::DoFireOnStateChange(nsIWebProgress* const, nsIRequest* const, int&, tag_nsresult)|EXCEPTION_ACCESS_VIOLATION_EXEC (10 crashes)
    100% (10/10) vs.   0% (322/121327) idvaultaddin@whitesky
         30% (3/10) vs.   0% (8/121327) 1.13.219.2
         70% (7/10) vs.   0% (20/121327) 1.13.220.4
          0% (0/10) vs.   0% (56/121327) 1.13.327.1
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [Win8] → [Win8][fixed in Whitesky's ID Vault 1.13.327.1]
Yes, after some more days it still looks good. :)
For the moment, within last month, there aren't any crash reports in Socorro regarding Firefox 22, for neither one of the two signatures of this crash.
This bug is not fixed. It has only morphed into bug 878845 with the same volume: #4 top crasher in 21.0 on Windows 8.

(In reply to Simona B [QA] from comment #25)
> Are these crashes related with this bug? Should I file a new bug for the
> above reports?
They are low volume crashes that don't need to be tracked in Bugzilla.
You need to log in before you can comment on or make changes to this bug.