691364 - OOM crash in nsUrlClassifierDBServiceWorker::AddNoise

Status: VERIFIED FIXED

(Toolkit :: General, defect)

Description

[Scoobidiver (away)]

It's a new crash signature that first appeared in 8.0a1/20110808030804.
It's #26 top crasher in 8.0b1.

Stack traces look like:
Frame 	Module 	Signature [Expand] 	Source
0 	mozalloc.dll 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:77
1 	mozalloc.dll 	mozalloc_handle_oom 	memory/mozalloc/mozalloc_oom.cpp:54
2 	xul.dll 	nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity 	obj-firefox/dist/include/nsTArray-inl.h:125
3 	xul.dll 	nsTArray<nsUrlClassifierLookupResult,nsTArrayDefaultAllocator>::AppendElements 	obj-firefox/dist/include/nsTArray.h:854
4 	xul.dll 	nsUrlClassifierDBServiceWorker::AddNoise 	toolkit/components/url-classifier/nsUrlClassifierDBService.cpp:1791
5 	xul.dll 	nsUrlClassifierDBServiceWorker::DoLookup 	toolkit/components/url-classifier/nsUrlClassifierDBService.cpp:1734
6 	xul.dll 	nsUrlClassifierDBServiceWorker::HandlePendingLookups 	
7 	xul.dll 	nsUrlClassifierDBServiceWorker::Lookup 	toolkit/components/url-classifier/nsUrlClassifierDBService.cpp:1812
8 	xul.dll 	UrlClassifierDBServiceWorkerProxy::LookupRunnable::Run 	toolkit/components/url-classifier/nsUrlClassifierProxies.cpp:65
9 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:631
10 	xul.dll 	nsThreadStartupEvent::Run 	xpcom/threads/nsThread.cpp:201
11 	nspr4.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:426
12 	nspr4.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:122
13 	msvcr80.dll 	_callthreadstartex 	f:\\dd\\vctools\\crt_bld\\self_x86\\crt\\src\\threadex.c:348
14 	msvcr80.dll 	_threadstartex 	f:\\dd\\vctools\\crt_bld\\self_x86\\crt\\src\\threadex.c:326
15 	kernel32.dll 	BaseThreadStart 	

More reports at:
https://crash-stats.mozilla.com/report/list?range_value=30&range_unit=days&signature=mozalloc_abort%28char%20const*%20const%29%20|%20mozalloc_handle_oom%28%29%20|%20nsTArray_base%3CnsTArrayDefaultAllocator%3E%3A%3AEnsureCapacity%28unsigned%20int%2C%20unsigned%20int%29%20|%20nsTArray%3CnsUrlClassifierLookupResult%2C%20nsTArrayDefaultAllocator%3E%3A%3AAppendElements%28unsigned%20int%29%20|%20nsUrlClass...

Comment 1

[Scoobidiver (away)]

(In reply to Scoobidiver from comment #0)
> It's a new crash signature that first appeared in 8.0a1/20110808030804.
Wrong. It first appeared in 8.0a1/20110802:
https://crash-stats.mozilla.com/report/list?range_value=30&range_unit=days&date=2011-08-17&signature=mozalloc_abort%28char%20const*%20const%29%20|%20mozalloc_handle_oom%28%29%20|%20nsTArray_base%3CnsTArrayDefaultAllocator%3E%3A%3AEnsureCapacity%28unsigned%20int%2C%20unsigned%20int%29%20|%20nsTArray%3CnsUrlClassifierLookupResult%2C%20nsTArrayDefaultAllocator%3E%3A%3AAppendElements%28unsigned%20int%29%20|%20nsUrlClass%2E%2E%2E
The regression range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f92e021f1f44&tochange=a43c3080f472

Comment 2

[Christian Holler (:decoder)]

I've seen this in my malware tool as well (seems to be related to safe browsing), mainly with the URL punchng.com, a news site that was listed as malware infected at 2011-10-03, but has been delisted again.

Comment 3

[Bob Clary [:bc] (inactive)]

According to bp-e99c1619-7eab-4d7e-800d-5e3a62111012, this is also related to the malware attacks described in http://www.theregister.co.uk/2011/10/14/mass_website_inection_grows/ for the strongdefenseiz.in variant. There is only this one instance from the associated urls since August though.

Comment 4

[Gian-Carlo Pascutto [:gcp]]

>http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f92e021f1f44&tochange=a43c3080f472

That has:
b4165ae3685f	Gian-Carlo Pascutto — Bug 667075 - Use nsIRandomGenerator instead of querying SQLite. r=dcamp

which was backed out in:
https://bugzilla.mozilla.org/show_bug.cgi?id=706740

So this one may have been fixed in:
 * Nightly from 2011-12-02 and onward
 * Aurora from 2011-12-08 and onward
 * Beta built after 2011-12-08 (ie. 9.0b6 -- the next beta)
 * Release built after 2011-12-08 (ie. 9.0 -- the next release)

Comment 5

[timeless]

mozalloc!mozalloc_abort(char * msg = 0x5a5ba33f "???")+0x2b
mozalloc!mozalloc_handle_oom(void)+0xa
xul!nsTArray_base<nsTArrayDefaultAllocator>::EnsureCapacity(unsigned int capacity = 0, unsigned int elemSize = 0xd33fa64)+0xfb
xul!nsTArray<nsIPresShell *,nsTArrayDefaultAllocator>::AppendElements<nsIPresShell *>(class nsIPresShell ** array = 0x5a5ba33f, unsigned int arrayLen = 0xd33fa64)+0x13
xul!nsUrlClassifierStore::ReadPrefixes(class nsTArray<unsigned int,nsTArrayDefaultAllocator> * array = 0x0d33fa64, unsigned int aKey = 0xaa20e513)+0xb3

0:018:x86> ?? array->mHdr->mLength
unsigned int 0n130046

This seems like a large allocation. wasn't there logic about trying large allocs and gracefully failing them? -- answer, it's called FallibleTArray:
  http://mxr.mozilla.org/mozilla-central/ident?i=FallibleTArray

xul!nsUrlClassifierDBServiceWorker::ConstructPrefixSet(void)+0x4d
xul!nsUrlClassifierDBServiceWorker::ApplyUpdate(void)+0x4f
xul!nsUrlClassifierDBServiceWorker::FinishUpdate(void)+0x4d
xul!nsRunnableMethodImpl<unsigned int (void)+0xf
xul!nsThread::ProcessNextEvent(bool mayWait = <Memory access error>, bool * result = <Memory access error>)+0x181
xul!nsThreadStartupEvent::Run(void)+0x25
nspr4!_PR_NativeRunThread(void * arg = 0x12a5f000)+0x120
nspr4!pr_root(void * arg = 0x74752a47)+0xd
MSVCR80!_callthreadstartex(void)+0x1b
MSVCR80!_threadstartex(void * ptd = 0x777a9ed2)+0x66
KERNEL32!BaseThreadInitThunk+0xe
ntdll_77770000!__RtlUserThreadStart+0x70
ntdll_77770000!_RtlUserThreadStart+0x1b

Comment 6

[Gian-Carlo Pascutto [:gcp]]

The AppendElements with AddNoise in the callstack is distinct from the one with ReadPrefixes (and friends) in the callstack. Comment 1 and 5 indeed look like duplicates of bug 702217 but I see no evidence this is so for the original report.

As noted in comment 4, I think this may be a duplicate of 667075, specifically if it disappeared after the noted dates.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

No more crashes at recent dates, so fixed by the backout of bug 667075.

Comment 8

[Scoobidiver (away)]

I see no crash signatures containing nsUrlClassifierDBServiceWorker::AddNoise in 9.0.1.