1374211 - Crash in OOM | large | NS_ABORT_OOM | nsTArray_base<T>::EnsureCapacity<T> | nsTArray_Impl<T>::AppendElement<T> | mozilla::safebrowsing::ChunkSet::Write

Status: RESOLVED WONTFIX

(Toolkit :: Safe Browsing, defect, P5)

Description

[baffclan]

This bug was filed from the Socorro interface and is 
report bp-a0c06ef5-a919-48be-9794-3a7420170619,
       bp-a64b4611-7679-45c2-9ecf-06ba80170619,
       bp-1ae80d45-0cae-4862-a6c0-129d40170619.
=============================================================
Crashing Thread (42), Name: Classifier Update
Frame 	Module 	Signature 	Source
0 	xul.dll 	NS_ABORT_OOM(unsigned __int64) 	xpcom/base/nsDebugImpl.cpp:610
1 	xul.dll 	nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity<nsTArrayInfallibleAllocator>(unsigned __int64, unsigned __int64) 	obj-firefox/dist/include/nsTArray-inl.h:128
2 	xul.dll 	nsTArray_Impl<unsigned int, nsTArrayInfallibleAllocator>::AppendElement<unsigned int, nsTArrayInfallibleAllocator>(unsigned int&&) 	obj-firefox/dist/include/nsTArray.h:2198
3 	xul.dll 	mozilla::safebrowsing::ChunkSet::Write(nsIOutputStream*) 	toolkit/components/url-classifier/ChunkSet.cpp:161
4 	xul.dll 	mozilla::safebrowsing::HashStore::WriteFile() 	toolkit/components/url-classifier/HashStore.cpp:990
5 	xul.dll 	mozilla::safebrowsing::Classifier::UpdateHashStore(nsTArray<mozilla::safebrowsing::TableUpdate*>*, nsACString const&) 	toolkit/components/url-classifier/Classifier.cpp:1276
6 	xul.dll 	mozilla::safebrowsing::Classifier::ApplyUpdatesBackground(nsTArray<mozilla::safebrowsing::TableUpdate*>*, nsACString&) 	toolkit/components/url-classifier/Classifier.cpp:827
7 	xul.dll 	<lambda_b644b910725263d7c075fabac4c13d47>::operator() 	toolkit/components/url-classifier/Classifier.cpp:746
8 	xul.dll 	mozilla::detail::RunnableFunction<<lambda_b644b910725263d7c075fabac4c13d47> >::Run() 	obj-firefox/dist/include/nsThreadUtils.h:460
9 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1428
10 	xul.dll 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/threads/nsThreadUtils.cpp:475
11 	xul.dll 	mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:368
12 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:311
13 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc:291
14 	xul.dll 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp:503
15 	nss3.dll 	PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:397
16 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:95
17 	ucrtbase.dll 	o__realloc_base 	
18 	kernel32.dll 	BaseThreadInitThunk 	
19 	ntdll.dll 	RtlUserThreadStart 	



Application Basics: 
Name: Firefox
Version: 56.0a1
Build ID: 20170618030207
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
OS: Windows_NT 10.0

Comment 1

[Nathan Froyd [:froydnj]]

This looks like some sort of overflow-leading-to-OOM; the allocation amount is 2PB (!).

Francois, can you have somebody take a look at this?  An overflow like this seems entirely avoidable, and indicative of some sort of logic error.

Comment 2

[baffclan]

Crash in [@ nsTArray_Impl<T>::AppendElement<T> | nsContainerFrame::GetChildLists ]
bp-d89f1a84-489b-4189-b269-2814d0170619

Comment 3

[Nathan Froyd [:froydnj]]

(In reply to baffclan from comment #2)
> Crash in [@ nsTArray_Impl<T>::AppendElement<T> |
> nsContainerFrame::GetChildLists ]
> bp-d89f1a84-489b-4189-b269-2814d0170619

This is a different crash; the ones this bug was filed with are OOM crashes and this one is not.  Please file a different bug.

Comment 4

[baffclan]

(In reply to Nathan Froyd [:froydnj] from comment #3)
> This is a different crash; the ones this bug was filed with are OOM crashes
> and this one is not.  Please file a different bug.
thanks for comment.
Because there was the same point"nsTArray_Impl<T>::AppendElement<T>" as the crash signature, I thought it was a related bug.

I filed a bug 1374871.

Comment 5

[Dimi Lee [:dimi]]

This bug happened when we added too many chunks before writing chunk data to disk[1], but given that we'll clear chunk when it meets its capacity (1024)[2], this error shouldn't happen in normal code flow.

I think this is cuased by memory corruption and since this crash signature only happened 3 times (within 40sec) in single build, I'll mark this bug as P5.

[1] https://dxr.mozilla.org/mozilla-central/source/toolkit/components/url-classifier/ChunkSet.cpp#161
[2] https://dxr.mozilla.org/mozilla-central/source/toolkit/components/url-classifier/ChunkSet.cpp#163

Comment 6

[baffclan]

(In reply to Dimi Lee[pto until 9/23][:dimi][:dlee] from comment #5)
> I think this is cuased by memory corruption and since this crash signature
> only happened 3 times (within 40sec) in single build, I'll mark this bug as
> P5.
If you expand the search range in 6 months, another crash report will be found.
see bp-a18254f8-5a37-4494-a93f-88a6d2170411

Comment 7

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.