798778 - crash in mozilla::safebrowsing::Classifier::MarkSpoiled

Status: RESOLVED DUPLICATE of bug 797302

(Toolkit :: Safe Browsing, defect)

Description

[Scoobidiver (away)]

It started spiking around September 30.

Signature 	nsTHashtable<nsBaseHashtableET<nsCStringHashKey, nsCOMPtr<nsIUrlClassifierHashCompleter> > >::RemoveEntry(nsACString_internal const&) More Reports Search
UUID	0cf13e62-2df4-46ca-a30a-88dc22121004
Date Processed	2012-10-04 11:12:29
Uptime	4
Last Crash	10.8 minutes before submission
Install Age	2.8 hours since version was first installed.
Install Time	2012-10-04 13:17:33
Product	Firefox
Version	18.0a1
Build ID	20121002030526
Release Channel	nightly
OS	Windows NT
OS Version	5.1.2600 Service Pack 3
Build Architecture	x86
Build Architecture Info	AuthenticAMD family 16 model 4 stepping 3
Crash Reason	EXCEPTION_ACCESS_VIOLATION_WRITE
Crash Address	0x10602e5e
App Notes 	
AdapterVendorID: 0x10de, AdapterDeviceID: 0x0de0, AdapterSubsysID: 00000000, AdapterDriverVersion: 6.14.12.9610
Processor Notes 	WARNING: JSON file missing Add-ons
EMCheckCompatibility	True
Adapter Vendor ID	0x10de
Adapter Device ID	0x0de0
Total Virtual Memory	2147352576
Available Virtual Memory	1969709056
System Memory Use Percentage	30
Available Page File	3604377600
Available Physical Memory	1492185088

Frame 	Module 	Signature 	Source
0 		@0x8148265 	
1 	xul.dll 	nsTHashtable<nsBaseHashtableET<nsCStringHashKey,nsCOMPtr<nsIUrlClassifierHashCom 	obj-firefox/dist/include/nsTHashtable.h:198
2 	xul.dll 	mozilla::safebrowsing::Classifier::MarkSpoiled 	toolkit/components/url-classifier/Classifier.cpp:426
3 	xul.dll 	nsUrlClassifierDBServiceWorker::FinishUpdate 	toolkit/components/url-classifier/nsUrlClassifierDBService.cpp:626
4 	xul.dll 	nsRunnableMethodImpl<tag_nsresult 	obj-firefox/dist/include/nsThreadUtils.h:349
5 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:612
6 	xul.dll 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:256
7 	nspr4.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:395
8 	nspr4.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:90
9 	msvcr100.dll 	_callthreadstartex 	f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:314
10 	msvcr100.dll 	_threadstartex 	f:\dd\vctools\crt_bld\self_x86\crt\src\threadex.c:292
11 	kernel32.dll 	BaseThreadStart 	

More reports at:
https://crash-stats.mozilla.com/query/query?&version=Firefox:18.0a1&range_value=4&range_unit=weeks&query_search=signature&query_type=contains&query=RemoveEntry&do_query=1

Comment 1

[Scoobidiver (away)]

It's #15 top browser crasher in 17.0b1.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Gian-Carlo have you had any luck investigating this yet? To give you an idea of timing, we are going to build tomorrow with Beta 2 and would consider any speculative fixes for this startupcrash/topcrash up to Beta 4 in two more weeks.

Comment 3

[Gian-Carlo Pascutto [:gcp]]

The point where it's crashing is a bit senseless, I think it may be fallout from bug 750988 and friends. I am working on a patch for that, but because we don't have STR it will take some days to verify if that patch is affecting anything (and we're not sure it fixes this, either).

Comment 4

[Scoobidiver (away)]

Here are some correlations in 17.0 Beta:
*Oct 15:
  PL_DHashTableOperate | nsTHashtable<nsBaseHashtableET<nsUint64HashKey, mozilla::dom::indexedDB::FileInfo*> >::RemoveEntry(unsigned __int64 const&)|EXCEPTION_ACCESS_VIOLATION_READ (112 crashes)
     21% (24/112) vs.   1% (110/18965) shimeng.dll (Shim Engine DLL)
     13% (15/112) vs.   0% (35/18965) aclayers.dll (Windows Compatibility DLL)
     13% (15/112) vs.   1% (169/18965) AcGenral.dll (Windows Compatibility DLL)
     13% (15/112) vs.   1% (256/18965) 4zhkstub.dll (MyWebSearch)
     18% (20/112) vs.   7% (1376/18965) mgAdaptersProxy.dll
     12% (13/112) vs.   1% (259/18965) mslbui.dll (LangageBar Add In)
     13% (14/112) vs.   3% (512/18965) 4zbrstub.dll (MyWebSearch)
      9% (10/112) vs.   0% (17/18965) snxPlugins.DLL (Avast AV)
      9% (10/112) vs.   0% (17/18965) snxBorder.dll (Avast AV)
     15% (17/112) vs.   6% (1204/18965) idmmkb.dll (Interent Download Manager)
      9% (10/112) vs.   0% (22/18965) acgenral.dll (Windows Compatibility DLL)
      9% (10/112) vs.   1% (212/18965) AcLayers.dll (Windows Compatibility DLL)
      6% (7/112) vs.   0% (46/18965) Mpk.dll (Logger.HQM)
      6% (7/112) vs.   1% (160/18965) bcryptPrimitives.dll (Windows Cryptographic Primitives Library)

*Oct 16:
  PL_DHashTableOperate | nsTHashtable<nsBaseHashtableET<nsUint64HashKey, mozilla::dom::indexedDB::FileInfo*> >::RemoveEntry(unsigned __int64 const&)|EXCEPTION_ACCESS_VIOLATION_READ (304 crashes)
     27% (82/304) vs.   1% (241/34589) shimeng.dll (Shim Engine DLL)
     22% (68/304) vs.   1% (425/34589) AcGenral.dll (Windows Compatibility DLL)
     16% (48/304) vs.   0% (88/34589) aclayers.dll (Windows Compatibility DLL)
     12% (35/304) vs.   1% (478/34589) AcLayers.dll (Windows Compatibility DLL)
     19% (57/304) vs.  10% (3586/34589) msctfime.ime (Microsoft Text Frame Work Service IME)
     23% (70/304) vs.  15% (5236/34589) MSCTFIME.IME (Microsoft Text Frame Work Service IME)
      7% (21/304) vs.   2% (521/34589) mslbui.dll (LangageBar Add In)

Comment 5

[Gian-Carlo Pascutto [:gcp]]

Attachment: Patch 1. Properly abort when initializing fails.

https://tbpl.mozilla.org/?tree=Try&rev=b2fb707e9146

Comment 6

[Gian-Carlo Pascutto [:gcp]]

Comment on attachment 672202 [details] [diff] [review]
Patch 1. Properly abort when initializing fails.

Oops, wrong bug!

Comment 7

[Gian-Carlo Pascutto [:gcp]]

Gawd, I'm dumb. I inferred in bug 797302 that that crash was caused by Classifier::Open failing and returning prematurely, causing the CryptoHash not to be initialized. 

So, what else is happening in that initialization:
http://mxr.mozilla.org/mozilla-central/source/toolkit/components/url-classifier/Classifier.cpp#208

Oh, we initialize the hashtable that crashes here...

The fix for bug 797302 will fix this bug as well. There's still the question why for some people in the field Classifier::Open fails. That would be good to find out as they will run without SafeBrowsing.

Comment 8

[Gian-Carlo Pascutto [:gcp]]

Going to duplicate this based on the high likelyhood that bug 797302, which just landed, had the same cause and will fix this.

Comment 9

[bhavana bajaj [:bajaj]]

Setting the tracking flags to " - " as it is a resolved dup of a tracked bug (bug 797302)