http://bugs.winehq.org/show_bug.cgi?id=28023
Summary: CoreAudio queue memory leak Product: Wine Version: 1.3.25 Platform: x86 OS/Version: Mac OS X 10.5 Status: UNCONFIRMED Severity: normal Priority: P2 Component: mmdevapi AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net CC: aeikum@codeweavers.com
While working on a patch to fix the Get/ReleaseBuffer ordering, see bug #27184 comment #3, I found a bug in memory management in winecoreaudio's mmdevapi.
510 HeapFree(GetProcessHeap(), 0, This->public_buffer); but public_buffer originates from 1625 sc = AudioQueueAllocateBuffer(This->aqueue, bytes, 1626 &This->public_buffer); The APIs don't match. It currently doesn't crash because public_buffer is NULL upon regular exit. This matches: 1634 AudioQueueFreeBuffer(This->aqueue, This->public_buffer);
That would be easy to fix, but it leads to question how AudioClient_Release frees the buffer queue.
502 if(This->aqueue) 503 AudioQueueDispose(This->aqueue, 1);
I suppose that Dispose gets rid of all the MacOS-level elements left in the queue, but I doubt it can handle the additional AQBuffer that Wine links to every object via the mUserData slot.
1632 buf = HeapAlloc(GetProcessHeap(), 0, sizeof(AQBuffer)); 1640 This->public_buffer->mUserData = buf;
Therefore I believe Wine must iterate through the list (aqueue or avail_buffers?) and free remaining objects one by one.
As I'm not familiar with the MacOS API's, I'd like somebody knowledgeable (Andrew, Ken?), to check this issue and write the patch.
BTW, I believe that correct freeing should first return This->public_buffer into the queue -- where it originated -- like I did in my ordering patch, then delete the whole queue.
+ if(This->public_buffer){ + AQBuffer *buf = This->public_buffer->mUserData; + list_add_tail(&This->avail_buffers, &buf->entry); + This->public_buffer = NULL; + }