<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GStreamer] WebAudio: GstBuffer memory of silent channels is leaked"
href="https://bugs.webkit.org/show_bug.cgi?id=166884">166884</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[GStreamer] WebAudio: GstBuffer memory of silent channels is leaked
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>WebKit Local Build
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>OS</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Keywords</th>
<td>Gtk
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>Platform
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>cgarcia@igalia.com
</td>
</tr>
<tr>
<th>CC</th>
<td>bugs-noreply@webkitgtk.org, calvaris@igalia.com, slomo@coaxion.net, vjaquez@igalia.com, zan@falconsigh.net
</td>
</tr></table>
<p>
<div>
<pre>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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>