Reproduces on trunk, but no reliable testcase. Looks like a race condition, free and read stacks on different threads. ================================================================= ==23547== ERROR: AddressSanitizer heap-use-after-free on address 0x7f0a6bff8e98 at pc 0x7f0a97af44c9 bp 0x7f0a66fda690 sp 0x7f0a66fda688 READ of size 8 at 0x7f0a6bff8e98 thread T26 #0 0x7f0a97af44c9 in nsTArray_base<nsTArrayDefaultAllocator>::Length() const ../../dist/include/nsTArray.h:192 #1 0x7f0a97b000ba in mozilla::(anonymous namespace)::MediaStreamGraphThreadRunnable::Run() content/media/MediaStreamGraph.cpp:1418 #2 0x7f0a9901cc64 in NS_ProcessNextEvent_P(nsIThread*, bool) obj-firefox/xpcom/build/nsThreadUtils.cpp:217 #3 0x7f0a990de3ed in nsThread::ShuttingDown() xpcom/threads/nsThread.h:58 #4 0x7f0a9daf489f in _pt_root nsprpub/pr/src/pthreads/ptthread.c:159 #5 0x42795c in __asan::AsanThread::ThreadStart() 0x7f0a6bff8e98 is located 24 bytes inside of 160-byte region [0x7f0a6bff8e80,0x7f0a6bff8f20) freed by thread T0 here: #0 0x4248b2 in free #1 0x7f0a97b0019d in mozilla::(anonymous namespace)::MediaStreamGraphShutDownRunnable::Run() ../../dist/include/mozilla/mozalloc.h:224 #2 0x7f0a9901cc64 in NS_ProcessNextEvent_P(nsIThread*, bool) obj-firefox/xpcom/build/nsThreadUtils.cpp:217 #3 0x7f0a98d1b0d8 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:82 #4 0x7f0a99164b9c in ~AutoRunState ipc/chromium/src/base/message_loop.cc:495 #5 0x7f0a98a49fce in nsBaseAppShell::Run() widget/xpwidgets/nsBaseAppShell.cpp:165 #6 0x7f0a95f13410 in XREMain::XRE_main(int, char**, nsXREAppData const*) toolkit/xre/nsAppRunner.cpp:3864 #7 0x7f0a95f144ab in XRE_main toolkit/xre/nsAppRunner.cpp:3940 #8 0x408d26 in do_main(int, char**) browser/app/nsBrowserApp.cpp:160 #9 0x7f0a9e942c4d in __libc_start_main /build/buildd/eglibc-2.11.1/csu/libc-start.c:258 previously allocated by thread T0 here: #0 0x424972 in __interceptor_malloc #1 0x7f0a9be211a9 in moz_xmalloc memory/mozalloc/mozalloc.cpp:54 Thread T26 created by T0 here: #0 0x4204b5 in pthread_create #1 0x7f0a9daf08af in _PR_CreateThread nsprpub/pr/src/pthreads/ptthread.c:393 #2 0x7f0a9daf0308 in PR_CreateThread nsprpub/pr/src/pthreads/ptthread.c:476 ==23547== ABORTING Stats: 224M malloced (246M for red zones) by 555057 calls Stats: 63M realloced by 26859 calls Stats: 192M freed by 304029 calls Stats: 56M really freed by 87570 calls Stats: 452M (115781 full pages) mmaped in 113 calls mmaps by size class: 8:409575; 9:57337; 10:20475; 11:14329; 12:5120; 13:3584; 14:1792; 15:384; 16:704; 17:128; 18:352; 19:48; 20:16; mallocs by size class: 8:448948; 9:58529; 10:19258; 11:15813; 12:5297; 13:3626; 14:1808; 15:460; 16:754; 17:148; 18:356; 19:46; 20:14; frees by size class: 8:221668; 9:43579; 10:15245; 11:12709; 12:4297; 13:3356; 14:1570; 15:403; 16:678; 17:129; 18:341; 19:42; 20:12; rfrees by size class: 8:59999; 9:12785; 10:4920; 11:6721; 12:899; 13:593; 14:1049; 15:151; 16:365; 17:44; 18:27; 19:16; 20:1; Stats: malloc large: 564 small slow: 2703 Shadow byte and word: 0x1fe14d7ff1d3: fd 0x1fe14d7ff1d0: fd fd fd fd fd fd fd fd More shadow bytes: 0x1fe14d7ff1b0: fa fa fa fa fa fa fa fa 0x1fe14d7ff1b8: fa fa fa fa fa fa fa fa 0x1fe14d7ff1c0: fa fa fa fa fa fa fa fa 0x1fe14d7ff1c8: fa fa fa fa fa fa fa fa =>0x1fe14d7ff1d0: fd fd fd fd fd fd fd fd 0x1fe14d7ff1d8: fd fd fd fd fd fd fd fd 0x1fe14d7ff1e0: fd fd fd fd fd fd fd fd 0x1fe14d7ff1e8: fd fd fd fd fd fd fd fd 0x1fe14d7ff1f0: fa fa fa fa fa fa fa fa
Created attachment 643003 [details] [diff] [review] fix I think this should fix it.
https://hg.mozilla.org/mozilla-central/rev/58525c0d69f2 Will this fix things like: https://bugzilla.mozilla.org/show_bug.cgi?id=759946#c482 ?
Comment on attachment 643003 [details] [diff] [review] fix Review of attachment 643003 [details] [diff] [review]: ----------------------------------------------------------------- We should take this security fix on Aurora and Beta.
Does this affect ESR-10 as well or is it a regression from a more recent change?
This file wasn't created until April 30 2012, so I believe ESR-10 should be unaffected.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #5) > We should take this security fix on Aurora and Beta. I'm assuming this is low risk given the nomination, but it would be great to get that down on paper.
Yes, there is no risk, this code is almost entirely unused at the moment.
Just a fyi, i haven't seen this crash happen again.
(In reply to Ed Morley [:edmorley] from comment #3) > Will this fix things like: > https://bugzilla.mozilla.org/show_bug.cgi?id=759946#c482 ? Bug 759946 was occurring 5-10 times a day on trunk trees - and has not since this landed on inbound/m-c. The last instances on aurora/beta were also just before the comment 10 landing. Looks like this fixed the [orange] too \o/ Thank you :-D
Flagging qa- for verification since this bug does not have a reproducible testcase.