[Bug 29657] New: winecoreaudio memory management and locking

http://bugs.winehq.org/show_bug.cgi?id=29657

Bug #: 29657
           Summary: winecoreaudio memory management and locking
           Product: Wine
           Version: 1.3.37
          Platform: x86
        OS/Version: Mac OS X
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: mmdevapi
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

Running my render tests in a loop sometimes causes an endless sequence of
errors

wine(4470,0x40805a00) malloc: *** error for object 0x4022e310: double free
*** set a breakpoint in malloc_error_break to debug

Process analysis shows that IAC_Release/DisposeQueue is involved
 1465 func_render
    1465 test_clock
      1465 AudioClient_Release
        1465 AudioQueueDispose
          1465 AQServer_DisposeQueue
            1465 AudioQueueObject::~AudioQueueObject()
  100.000%    1465 free

A possibly related issue is a deadlock mentioned in bug #28023, comment #4

[Bug 29657] winecoreaudio memory management and locking seems to be broken

http://bugs.winehq.org/show_bug.cgi?id=29657

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|winecoreaudio memory        |winecoreaudio memory
                   |management and locking      |management and locking
                   |                            |seems to be broken

[Bug 29657] winecoreaudio memory management and locking seems to be broken

http://bugs.winehq.org/show_bug.cgi?id=29657

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |28023
   Target Milestone|---                         |1.4.0

--- Comment #1 from Jörg Höhle  2012-01-21 07:33:03 CST ---
Spinlocks in callbacks and undue mid-function unlocks (while e.g. the timer
callback is still active) indeed appear to cause the double free as well as
random dead-locks during my tests.
Now I have to turn my 10 liner test hack into a 100 line submitable patch and
lock-free design.

[Bug 29657] winecoreaudio memory management and locking seems to be broken

http://bugs.winehq.org/show_bug.cgi?id=29657

--- Comment #2 from Jörg Höhle  2012-01-23 08:29:34 CST ---
I had not enough time with the Mac over the week-end. The sketch is:
1. Introduce lock-less callbacks and remove mid-function unlocks,
   adding This->queued_buffers and a boolean "used" slot to each AQBuf;
   The new cb is merely: buf->used = 0;
   Requires code to move from queued_buffers to This->avail_buffers;
2. Change remaining OSSpinLock to CriticalSection;
3. Later perhaps merge the current GetPosition queued_bufinfos into
queued_buffers.
   The timestamp therein would benefit capture too.

[Bug 29657] winecoreaudio memory management and locking seems to be broken

http://bugs.winehq.org/show_bug.cgi?id=29657

pete  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 29657] winecoreaudio memory management and locking seems to be broken

http://bugs.winehq.org/show_bug.cgi?id=29657

--- Comment #3 from Jörg Höhle  2012-01-29 14:15:07 CST ---
Created attachment 38597
  --> http://bugs.winehq.org/attachment.cgi?id=38597
lockless callback design for winecoreaudio

Here are the 3 parts.  The wineoss part needs to be completed.

Obviously the code is begging for merging the third queue from
get_current_aqbuffer_position, perhaps via resolution of bug #29602. There
should be 2 queues only, and AQBuffer integrate sample time data.

Now you can run hundreds of test iterations without dead-lock and with little
CPU usage.

I've had one test run where EnqueueBuffer failed in render.c.
AudioRenderClient_ReleaseBuffer (0x149480)->(20671, 2)
er::AudioRenderClient_ReleaseBuffer Unable to enqueue buffer: fffefb8e
That was before I merged Andrew's GetPosition patch from bug #29602.

Also, WaitForSingleObject(event, 70) fails with rc=102 in rare cases.  That
means that there's either a flaw in the logic, or even on a dual core MacOS,
the CreateTimerQueue events can be very far from 10ms apart... I can't remember
whether that happened before I introduced EXECUTEINTIMERTHREAD though.

[Bug 29657] winecoreaudio memory management and locking seems to be broken

http://bugs.winehq.org/show_bug.cgi?id=29657

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |source
                 CC|                            |[e-mail]

[Bug 29657] winecoreaudio memory management and locking seems to be broken

http://bugs.winehq.org/show_bug.cgi?id=29657

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Jörg Höhle  2012-02-02 05:35:22 CST ---
commit 4b888861f95d8199f420a8ab7c1c725be996fa26 etc.

What's still needed in all 3 drivers is a way to signal errors like MS might
do, and such that our own clients (winmm & dsound) can make sense of it.
For instance, I don't think that an OOM error in our ReleaseBuffer is
acceptable or expected.

I'd appreciate if somebody could run tests with pluggable HW on native.

[Bug 29657] winecoreaudio memory management and locking seems to be broken

http://bugs.winehq.org/show_bug.cgi?id=29657

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #5 from Alexandre Julliard  2012-02-02 13:37:50 CST ---
Closing bugs fixed in 1.4-rc2.

[Bug 29657] winecoreaudio memory management and locking seems to be broken

http://bugs.winehq.org/show_bug.cgi?id=29657

Jerome Leclanche  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
      Fixed by SHA1|                            |4b888861f95d8199f420a8ab7c1
                   |                            |c725be996fa26
                 CC|                            |[e-mail]