[Webkit-unassigned] [Bug 166884] New: [GStreamer] WebAudio: GstBuffer memory of silent channels is leaked

[bugzilla-daemon at webkit.org]

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

            Bug ID: 166884
           Summary: [GStreamer] WebAudio: GstBuffer memory of silent
                    channels is leaked
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Local Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Keywords: Gtk
          Severity: Normal
          Priority: P2
         Component: Platform
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cgarcia at igalia.com
                CC: bugs-noreply at webkitgtk.org, calvaris at igalia.com,
                    slomo at coaxion.net, vjaquez at igalia.com,
                    zan at falconsigh.net

I can reproduce this very easily joining a flowdock channel, even when I have all sound notifications disabled, it seems we are playing silence all the time. I don't know if this is expected or not, because I don't know anything about web audio. The thing is that the memory of the web process keeps growing all the time while the chat room is open, and never ends growing. Valgrind shows we are leaking the memory of the GstBuffers, see:

==17405== 2,348,346 bytes in 3,542 blocks are definitely lost in loss record 15,722 of 15,730
==17405==    at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==17405==    by 0x1105D678: g_malloc (gmem.c:94)
==17405==    by 0x11075302: g_slice_alloc (gslice.c:1025)
==17405==    by 0xE1766E9: _sysmem_new_block (gstallocator.c:416)
==17405==    by 0xE181B81: gst_buffer_new_allocate (gstbuffer.c:838)
==17405==    by 0xE184EF7: default_alloc_buffer (gstbufferpool.c:234)
==17405==    by 0xE184FA5: do_alloc_buffer (gstbufferpool.c:274)
==17405==    by 0xE1852EC: default_acquire_buffer (gstbufferpool.c:1130)
==17405==    by 0xE18697F: gst_buffer_pool_acquire_buffer (gstbufferpool.c:1261)
==17405==    by 0x7182FF4: webKitWebAudioSrcLoop(_WebKitWebAudioSrc*) (in WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37.16.0)
==17405==    by 0xE1EBC70: gst_task_func (gsttask.c:334)
==17405==    by 0x1107F8DD: g_thread_pool_thread_proxy (gthreadpool.c:307)
==17405== 
==17405== 2,349,009 bytes in 3,543 blocks are definitely lost in loss record 15,723 of 15,730
==17405==    at 0x4C2ABAF: malloc (vg_replace_malloc.c:299)
==17405==    by 0x1105D678: g_malloc (gmem.c:94)
==17405==    by 0x11075302: g_slice_alloc (gslice.c:1025)
==17405==    by 0xE1766E9: _sysmem_new_block (gstallocator.c:416)
==17405==    by 0xE176820: _sysmem_copy (gstallocator.c:462)
==17405==    by 0xE1B3020: gst_memory_make_mapped (gstmemory.c:241)
==17405==    by 0xE182C45: gst_buffer_map_range (gstbuffer.c:1737)
==17405==    by 0x7153404: WebCore::mapGstBuffer(_GstBuffer*, unsigned int) (in WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37.16.0)
==17405==    by 0x7182F8B: webKitWebAudioSrcLoop(_WebKitWebAudioSrc*) (in WebKitBuild/Release/lib/libwebkit2gtk-4.0.so.37.16.0)
==17405==    by 0xE1EBC70: gst_task_func (gsttask.c:334)
==17405==    by 0x1107F8DD: g_thread_pool_thread_proxy (gthreadpool.c:307)
==17405==    by 0x1107EF04: g_thread_proxy (gthread.c:784)

And this is happening a lot of times per second. I cleaned up the code and added some smart pointers (will submit a patch) to make the code easier to follow and ensure we are not leaking any ref, and indeed we aren't. After a lot of debugging I've realized that GST_BUFFER_FLAG_GAP is the problem. I don't know why or whether it's a GStreamer bug or something we do wrong in WebKit, that's why I opened the bug here first. If I understood the flag correctly, it's actually an optimization, but it's not a problem to remove it because when the channel is silent the memory is filled with 0, so we will not play anything anyway. If that is the case and the bug is actually in GST, I would suggest to remove that until there's a new GST release with the bug fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170110/8a7df81a/attachment.html>