This happens when you run just content/media/webaudio/test/ under LSAN. The leak is on this line: NS_DispatchToMainThread(new ShutdownPoolsEvent()); My guess is that what is happening is that we're late enough in shutdown that the dispatch fails, and the ShutdownPoolsEvent() ends up leaking. If that's the case, it doesn't seem like a big deal. Here's the stack: Direct leak of 24 byte(s) in 1 object(s) allocated from: #0 0x468629 in __interceptor_malloc (/home/amccreight/mc/obj-x86_64-unknown-linux-gnu/dist/bin/firefox+0x468629) #1 0x7f2274fdbc35 in moz_xmalloc /home/amccreight/mc/memory/mozalloc/mozalloc.cpp:52 #2 0x7f225f679119 in operator new(unsigned long) /home/amccreight/mc/obj-x86_64-unknown-linux-gnu/content/media/../../dist/include/mozilla/mozalloc.h:201 #3 0x7f225f679119 in mozilla::SharedThreadPool::Release() /home/amccreight/mc/content/media/SharedThreadPool.cpp:168 #4 0x7f225f6d9acb in mozilla::RefPtr<mozilla::SharedThreadPool>::unref(mozilla::SharedThreadPool*) /home/amccreight/mc/obj-x86_64-unknown-linux-gnu/content/media/webaudio/../../../dist/include/mozilla/RefPtr.h:281 #5 0x7f225f6d9acb in ~RefPtr /home/amccreight/mc/obj-x86_64-unknown-linux-gnu/content/media/webaudio/../../../dist/include/mozilla/RefPtr.h:231 #6 0x7f225f6d9acb in ~nsTHashtable /home/amccreight/mc/content/media/webaudio/MediaBufferDecoder.h:76 #7 0x7f225f6d9acb in mozilla::dom::AudioContext::~AudioContext() /home/amccreight/mc/content/media/webaudio/AudioContext.cpp:112 #8 0x7f225f6d9953 in mozilla::dom::AudioContext::~AudioContext() /home/amccreight/mc/content/media/webaudio/AudioContext.cpp:105 #9 0x7f225bbcfc54 in SnowWhiteKiller::~SnowWhiteKiller() /home/amccreight/mc/xpcom/base/nsCycleCollector.cpp:2611 #10 0x7f225bbcf8c9 in nsCycleCollector::FreeSnowWhite(bool) /home/amccreight/mc/xpcom/base/nsCycleCollector.cpp:2778 #11 0x7f225bbd4dba in nsCycleCollector::BeginCollection(ccType, nsICycleCollectorListener*) /home/amccreight/mc/xpcom/base/nsCycleCollector.cpp:3705 #12 0x7f225bbd485f in nsCycleCollector::Collect(ccType, js::SliceBudget&, nsICycleCollectorListener*) /home/amccreight/mc/xpcom/base/nsCycleCollector.cpp:3546 #13 0x7f225bbd467b in nsCycleCollector::ShutdownCollect() /home/amccreight/mc/xpcom/base/nsCycleCollector.cpp:3499 #14 0x7f225bbd78f9 in nsCycleCollector_shutdown() /home/amccreight/mc/xpcom/base/nsCycleCollector.cpp:4210 #15 0x7f225bb9aa3a in mozilla::ShutdownXPCOM(nsIServiceManager*) /home/amccreight/mc/xpcom/build/nsXPComInit.cpp:900 #16 0x7f2260cc82ca in ScopedXPCOMStartup::~ScopedXPCOMStartup() /home/amccreight/mc/toolkit/xre/nsAppRunner.cpp:1202 #17 0x7f2260cd802a in XREMain::XRE_main(int, char**, nsXREAppData const*) /home/amccreight/mc/toolkit/xre/nsAppRunner.cpp:4108 #18 0x7f2260cd889e in XRE_main /home/amccreight/mc/toolkit/xre/nsAppRunner.cpp:4297 #19 0x47f378 in do_main(int, char**, nsIFile*) /home/amccreight/mc/browser/app/nsBrowserApp.cpp:282 #20 0x47f378 in main /home/amccreight/mc/browser/app/nsBrowserApp.cpp:643 #21 0x7f2273d93fff in __libc_start_main (/usr/lib/libc.so.6+0x1ffff)

FWIW, I've never seen this leak in a full Mochitest run, which further leads me to believe that it is just a shutdown thing.

(In reply to Andrew McCreight [:mccr8] from comment #0) > This happens when you run just content/media/webaudio/test/ under LSAN. > > The leak is on this line: > NS_DispatchToMainThread(new ShutdownPoolsEvent()); > > My guess is that what is happening is that we're late enough in shutdown > that the dispatch fails, and the ShutdownPoolsEvent() ends up leaking. If > that's the case, it doesn't seem like a big deal. Is ShutdownPoolsEvent the only thing leaked? It should also leak a log of things if ShutdownPoolsEvent not executed. And SharedThreadPool will hang in SpinUntilShutdown for sPools is true.

Yeah, I think it was just the one thing. I'll see if I can reduce it to a particular test case. (I was having some trouble when reducing the set of web audio test cases where it would hang, but I don't know if it is related to this.)

Mass closing do to inactivity. Feel free to re-open if still needed.