Closed Bug 691364 Opened 13 years ago Closed 13 years ago

OOM crash in nsUrlClassifierDBServiceWorker::AddNoise

Categories

(Toolkit :: General, defect)

Product:
Toolkit
Component:
General
Version:
8 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
firefox8 - ---

People

(Reporter: scoobidiver, Assigned: gcp)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

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...
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.
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.
Keywords: topcrash
Assignee: nobody → gpascutto
>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)
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
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
No more crashes at recent dates, so fixed by the backout of bug 667075.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
I see no crash signatures containing nsUrlClassifierDBServiceWorker::AddNoise in 9.0.1.
Blocks: 667075
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.