[Webkit-unassigned] [Bug 176265] New: Leak of allocation under WebCore::AudioSourceProviderAVFObjC::initCallback

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Sep 1 20:04:04 PDT 2017


https://bugs.webkit.org/show_bug.cgi?id=176265

            Bug ID: 176265
           Summary: Leak of allocation under
                    WebCore::AudioSourceProviderAVFObjC::initCallback
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media Elements
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: joepeck at webkit.org
                CC: eric.carlson at apple.com, jer.noble at apple.com

Leak of allocation under WebCore::AudioSourceProviderAVFObjC::initCallback

Seen on the Leaks bot:
https://build.webkit.org/LeaksViewer/?url=%2Fresults%2FApple%20Sierra%20%28Leaks%29%2Fr221463%20%282930%29%2F

Leak:
| start
| DumpRenderTreeMain(int, char const**) - DumpRenderTree.mm:1404
| dumpRenderTree(int, char const**) - DumpRenderTree.mm:1288
| runTest(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) - DumpRenderTree.mm:2024
| CFRunLoopRunSpecific
| __CFRunLoopRun
| __CFRunLoopDoSources0
| __CFRunLoopDoTimers
| __CFRunLoopDoTimer
| __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
| ____NSPeriodicInvokerScheduled_block_invoke 
| WTF::timerFired(__CFRunLoopTimer*, void*) - MainThreadSharedTimerCF.cpp:75
| WTF::dispatchFunctionsFromMainThread() - MainThread.cpp:132
| WebCore::MediaPlayerPrivateAVFoundation::scheduleMainThreadNotification(WebCore::MediaPlayerPrivateAVFoundation::Notification::Type, WTF::MediaTime const&) - MediaPlayerPrivateAVFoundation.cpp:771
| WebCore::MediaPlayerPrivateAVFoundation::dispatchNotification() - MediaPlayerPrivateAVFoundation.cpp:873
| WebCore::MediaPlayerPrivateAVFoundationObjC::tracksChanged() - MediaPlayerPrivateAVFoundationObjC.mm:2027
| WebCore::MediaPlayerPrivateAVFoundation::updateStates() - MediaPlayerPrivateAVFoundation.cpp:511
| WebCore::MediaPlayerPrivateAVFoundation::setPreload(WebCore::MediaPlayerEnums::Preload) - MediaPlayerPrivateAVFoundation.cpp:738
| WebCore::MediaPlayerPrivateAVFoundationObjC::createAVPlayerItem() - MediaPlayerPrivateAVFoundationObjC.mm:2640
| WebCore::AudioSourceProviderAVFObjC::createMix() -  AudioSourceProviderAVFObjC.mm:58
| MTAudioProcessingTapCreate 
| WebCore::AudioSourceProviderAVFObjC::initCallback(opaqueMTAudioProcessingTap const*, void*, void**) AudioSourceProviderAVFObjC.mm:243
| operator new(unsigned long)
| malloc

This seems to indicate that the object that may have leaked is the `AudioSourceProviderAVFObjC::TapStorage` allocated in `WebCore::AudioSourceProviderAVFObjC::initCallback`:

It seems the only `operator new` allocation is this TapStorage:

> void AudioSourceProviderAVFObjC::initCallback(MTAudioProcessingTapRef tap, void* clientInfo, void** tapStorageOut)
> {
>     ...
>     _this->m_tapStorage = new TapStorage(_this);
>     ...
> }

It seems very suspicious that in the destructor we handle a case where m_tapStorage is non-null but we don't delete it.

> AudioSourceProviderAVFObjC::~AudioSourceProviderAVFObjC()
> {
>     ...
>     if (m_tapStorage) {
>         std::lock_guard<Lock> lock(m_tapStorage->mutex);
>         m_tapStorage->_this = nullptr;
>         m_tapStorage = nullptr;
>     }
> }

We seem to delete it in `finalize` but not if we destructed our object ourselves. In the case where we destructed, how is TapStorage supposed to get released?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170902/208ef96f/attachment.html>


More information about the webkit-unassigned mailing list