Repeated use of decodeAudioData() causes leak
I made a test case that uses a single arrayBuffer to feed repeated calls to decodeAudioData() and see the "leak". But it's not really a "leak", per se. It's just that the garbage collector doesn't know how big these audio buffers actually are. Once their size is correctly reported to the GC, they are deleted much more rapidly, and a steady state of only a few live objects is attained.
<rdar://problem/12804159>
Created attachment 198445 [details] Patch
Attachment 198445 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCore/Modules/webaudio/AudioBuffer.cpp', u'Source/WebCore/Modules/webaudio/AudioBuffer.h', u'Source/WebCore/Modules/webaudio/AudioBuffer.idl', u'Source/WebCore/WebCore.xcodeproj/project.pbxproj', u'Source/WebCore/bindings/js/JSAudioBufferCustom.cpp']" exit_code: 1 Source/WebCore/bindings/js/JSAudioBufferCustom.cpp:27: You should add a blank line after implementation file's own header. [build/include_order] [4] Total errors found: 1 in 6 files If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 198448 [details] Patch Address the stylebot's review.
Comment on attachment 198448 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=198448&action=review r=me > Source/WebCore/Modules/webaudio/AudioBuffer.h:71 > + size_t extraMemoryCost() const; Slight nit: from the audio buffer's perspective, this is just "cost", not "extra cost".
Comment on attachment 198448 [details] Patch Attachment 198448 [details] did not pass efl-ews (efl): Output: http://webkit-queues.appspot.com/results/85192
Committed r148566: <http://trac.webkit.org/changeset/148566>