[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: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net 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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29657 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|winecoreaudio memory |winecoreaudio memory |management and locking |management and locking | |seems to be broken -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29657 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |28023 Target Milestone|--- |1.4.0 --- Comment #1 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29657 --- Comment #2 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29657 pete <vazz28(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vazz28(a)yahoo.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29657 --- Comment #3 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29657 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source CC| |aeikum(a)codeweavers.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29657 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #4 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29657 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Alexandre Julliard <julliard(a)winehq.org> 2012-02-02 13:37:50 CST --- Closing bugs fixed in 1.4-rc2. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=29657 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |4b888861f95d8199f420a8ab7c1 | |c725be996fa26 CC| |adys.wh(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.
participants (1)
-
wine-bugs＠winehq.org