Closed Bug 1305250 Opened 8 years ago Closed 8 years ago

Crash in _ZN5alloc3oom3oom17h3956399ac0d31bcdE

Categories

(Core :: Audio/Video: Playback, defect)

50 Branch
x86
Windows
defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
firefox50 --- fixed
firefox51 --- unaffected
firefox52 --- unaffected

People

(Reporter: philipp, Assigned: rillian)

References

Details

(Keywords: crash, regression)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-69203f7e-6fb0-4d59-a166-3e69b2160924.
=============================================================
Crashing Thread (100)
Frame 	Module 	Signature 	Source
0 	xul.dll 	_ZN5alloc3oom3oom17h3956399ac0d31bcdE 	
1 	xul.dll 	read_stbl<lib::BMFFBox<lib::BMFFBox<lib::BMFFBox<lib::BMFFBox<lib::capi::mp4parse_io>>>>> 	obj-firefox/media/src/libcollections/vec.rs:706
2 	xul.dll 	read_moov<lib::capi::mp4parse_io> 	media/libstagefright/binding/mp4parse/src/lib.rs:639
3 	xul.dll 	mp4parse_read 	media/libstagefright/binding/mp4parse/src/lib.rs:488
4 	xul.dll 	mp4_demuxer::MP4MetadataRust::MP4MetadataRust(mp4_demuxer::Stream*) 	media/libstagefright/binding/MP4Metadata.cpp:574
5 	xul.dll 	mp4_demuxer::MP4Metadata::MP4Metadata(mp4_demuxer::Stream*) 	media/libstagefright/binding/MP4Metadata.cpp:155
6 	xul.dll 	mozilla::MP4Demuxer::Init() 	dom/media/fmp4/MP4Demuxer.cpp:136
7 	xul.dll 	mozilla::MediaFormatReader::AsyncReadMetadata() 	dom/media/MediaFormatReader.cpp:264
8 	xul.dll 	mozilla::detail::ProxyRunnable<mozilla::MozPromise<RefPtr<mozilla::MetadataHolder>, mozilla::ReadMetadataFailureReason, 1>, mozilla::MediaDecoderReader>::Run() 	obj-firefox/dist/include/mozilla/MozPromise.h:960
9 	xul.dll 	mozilla::AutoTaskDispatcher::TaskGroupRunnable::Run() 	obj-firefox/dist/include/mozilla/TaskDispatcher.h:192
10 	xul.dll 	mozilla::TaskQueue::Runner::Run() 	xpcom/threads/TaskQueue.cpp:172
11 	xul.dll 	nsThreadPool::Run() 	xpcom/threads/nsThreadPool.cpp:227
12 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1068
13 	xul.dll 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp:290
14 	xul.dll 	mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:354
15 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:225
16 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc:205
17 	xul.dll 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp:463
18 	nss3.dll 	_PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:397
19 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:95
20 	ucrtbase.dll 	_crt_at_quick_exit 	
21 	kernel32.dll 	BaseThreadInitThunk 	
22 	ntdll.dll 	__RtlUserThreadStart 	
23 	ntdll.dll 	_RtlUserThreadStart 	

this rust crash signature is regressing in firefox 50 - just based on crashing thread frame #3 i'm guessing that might be related to bug 1267887.
in early crash data for 50.0b1 it's making up 0.2% of all browser crashes...
Ralph - looks OOMy.
Flags: needinfo?(giles)
Did you have a chance to investigate here, Ralph?
I hadn't. Having looked briefly...Assuming this is an oom in read_stbl()...yes, that's possible. It will allocate up to 1 MB for codec initialization data. That could be the cause here.

It will also try to read to several GB of sample table data if that much data is present in the resource. We could add a upper bound to the later case like we have in the codec initialization, but otherwise there's not much we can do in that case.

I note there have been no crashes from 50b6 or 50b7, so maybe the toolchain downgrade from bug 1305315 rearranged the code enough to block this particular signature.
Assignee: nobody → giles
Flags: needinfo?(giles)
No new instances since 50b5. Treating this as resolved by the toolchain downgrade in bug 1305315. Please re-open if we see more of them.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
See Also: → 1313333
See Also: → 1311868
You need to log in before you can comment on or make changes to this bug.