http://bugs.winehq.org/show_bug.cgi?id=28597
Bug #: 28597 Summary: winecfg page fault during sound test Product: Wine Version: 1.3.29 Platform: x86-64 OS/Version: Linux Status: NEW Keywords: download, regression, source Severity: trivial Priority: P2 Component: programs AssignedTo: wine-bugs@winehq.org ReportedBy: kennybobs@o2.co.uk CC: aeikum@codeweavers.com Classification: Unclassified Regression SHA1: b07a82c01dc0422719a98f20471f240b35d9e5db
Created attachment 36737 --> http://bugs.winehq.org/attachment.cgi?id=36737 wine-1.3.29-217-g5432611 console output
In wine-1.3.29-217-g5432611 open winecfg and the Audio tab. Hit "Test Sound" a LOT and fast and a page fault occurs.
Backtrace: =>0 0x7d5bbb6c WINMM_DevicesThreadProc+0x248(arg=0x1fc) [/home/test/wine-git/dlls/winmm/waveform.c:2072] in winmm (0x00bcea48) 1 0x7bc7f938 call_thread_func+0xb() in ntdll (0x00bcea58) 2 0x7bc7f976 call_thread_entry_point+0x33(entry=0x7d5bb924, arg=0x1fc) [/home/test/wine-git/dlls/ntdll/signal_i386.c:2499] in ntdll (0x00bceb38) 3 0x7bc8725f start_thread+0x1c6(info=0x7ffbcfb8) [/home/test/wine-git/dlls/ntdll/thread.c:405] in ntdll (0x00bcf398) 4 0xf7587e72 start_thread+0xd1(arg=0xbcfb70) [/build/buildd/eglibc-2.13/nptl/pthread_create.c:304] in libpthread.so.0 (0x00bcf498) 0x7d5bbb6c WINMM_DevicesThreadProc+0x248 [/home/test/wine-git/dlls/winmm/waveform.c:2072] in winmm: subl $20,%esp
The sound test continues regardless.
Does not occur in wine-1.3.29.
b07a82c01dc0422719a98f20471f240b35d9e5db is the first bad commit commit b07a82c01dc0422719a98f20471f240b35d9e5db Author: Andrew Eikum aeikum@codeweavers.com Date: Wed Oct 5 13:39:46 2011 -0500
winecfg: Reload winmm for each sound test.
Also localize the error dialog while we're in there.
:040000 040000 3b67f528b00a1b3770a0a24dab0a1d95bd774ce4 316e8f2bfed44a0e958e65e633e1426c505434bc M po :040000 040000 2edf3338c75c4cb754c80e9b0706bef900362f05 c14af07c12b0eb61eaa84665ab22c6e1644edd7a M programs
http://bugs.winehq.org/show_bug.cgi?id=28597
Andrew Eikum aeikum@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|trivial |normal
--- Comment #1 from Andrew Eikum aeikum@codeweavers.com 2011-10-07 10:48:57 CDT --- I think this is because winmm doesn't shut down its devices thread properly during process detach.
http://bugs.winehq.org/show_bug.cgi?id=28597
Ken Sharp kennybobs@o2.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|programs |winmm&mci
http://bugs.winehq.org/show_bug.cgi?id=28597
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #2 from Jörg Höhle hoehle@users.sourceforge.net 2011-10-19 14:00:42 CDT --- I tried wine-1.3.30-253-g6b0f110 to have a look at winecfg's new audio tab (with mmdevapi devices enumerated). Upon each launch, the very first click on "test sound" causes one crash dialog after the sound plays, but winecfg still works (no hang) and subsequent clicks work ok and produce sound. Backtrace: =>0 0x7da6d2f0 (0x0070eaa8) 1 0x7efaeb08 call_thread_func+0xb() in ntdll (0x006ceab8) [...] 5 0xb76d8a0e __clone+0x5d() in libc.so.6 (0x00000000) 0x7da6d2f0: -- no code accessible -- Using Ubuntu Intrepid 32bit with and without PulseAudio
Ken, you say x86-64 yet the pointers in your backtrace are 32bit.
http://bugs.winehq.org/show_bug.cgi?id=28597
--- Comment #3 from Ken Sharp kennybobs@o2.co.uk 2011-10-19 14:12:28 CDT --- It's a x86_64 system but I usually only compile the latest git in 32-bit unless testing a 64-bit app, and I do have the 32-bit libraries installed.
http://bugs.winehq.org/show_bug.cgi?id=28597
--- Comment #4 from Andrew Eikum aeikum@codeweavers.com 2011-10-26 10:56:33 CDT --- Created attachment 37127 --> http://bugs.winehq.org/attachment.cgi?id=37127 winecfg: Don't reload winmm for each audio test
Here's a patch to avoid the crash, and a proposal to fix it properly. From the patch:
I originally did this so that the user's changes to the Audio tab would take effect without having to relaunch winecfg. However, this causes crashes with WinMM's internal thread. We should be using MMDevAPI's IMMNotificationClient within WinMM to be informed when the device default changes. So this commit fixes the crashy behavior, but goes back to requiring a winecfg relaunch to have the settings take effect. After we implement IMMNotificationClient, we can do this correctly.
http://bugs.winehq.org/show_bug.cgi?id=28597
--- Comment #5 from Jörg Höhle hoehle@users.sourceforge.net 2011-10-27 02:53:51 CDT --- I don't understand why the future IMMNotificationClient would help. Your suspicion in comment #1 seems very reasonable, the user expects to have "test sound" take effect immediately (this was a long-standing bug), so the goal is to have winmm shut down properly and be able to reload it.
What does prevent winmm from shutting down its devices thread properly? your patch sounds like a work-around the bug that winmm may not unload properly, which sounds like it could potentially affect any app that dynamically loads it (probably a minority).
http://bugs.winehq.org/show_bug.cgi?id=28597
--- Comment #6 from Andrew Eikum aeikum@codeweavers.com 2011-10-27 07:42:57 CDT --- (In reply to comment #5)
I don't understand why the future IMMNotificationClient would help. Your suspicion in comment #1 seems very reasonable, the user expects to have "test sound" take effect immediately (this was a long-standing bug), so the goal is to have winmm shut down properly and be able to reload it.
WinMM would use IMMNotificationClient to know when the default has changed, and reroute its audio appropriately. MMDevAPI could monitor the registry in certain function calls (GetDefaultAudioEndpoint at least) and send notifications when it finds that the default has changed. Then WinMM never needs to be unloaded.
What does prevent winmm from shutting down its devices thread properly? your patch sounds like a work-around the bug that winmm may not unload properly, which sounds like it could potentially affect any app that dynamically loads it (probably a minority).
This is true. I believe there are ways to prevent DLLs from ever unloading, which would be a solution to that problem. I don't know enough about DLL loading and unloading to know how to test for this right now.
This all needs more tests, obviously, but the patch fixes this particular crash, at least.
http://bugs.winehq.org/show_bug.cgi?id=28597
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |00629cb0b3c7c3b25d8ccbfc567 | |55344dc9a1e89 Status|NEW |RESOLVED CC| |adys.wh@gmail.com Resolution| |FIXED
--- Comment #7 from Jerome Leclanche adys.wh@gmail.com 2011-10-28 14:18:53 CDT --- Should be fixed by 00629cb0b3c7c3b25d8ccbfc56755344dc9a1e89
http://bugs.winehq.org/show_bug.cgi?id=28597
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #8 from Alexandre Julliard julliard@winehq.org 2011-11-04 14:14:24 CDT --- Closing bugs fixed in 1.3.32.
http://bugs.winehq.org/show_bug.cgi?id=28597
--- Comment #9 from Jörg Höhle hoehle@users.sourceforge.net 2011-11-04 16:15:55 CDT --- How can you expect winmm to shut down properly when there's no mechanism in WINMM_DevicesThreadProc to stop? That thread runs forever. So it's actually surprising we don't see random crashes from that thread when winmm is forcefully unloaded when the app exits.
http://bugs.winehq.org/show_bug.cgi?id=28597
--- Comment #10 from Alexandre Julliard julliard@winehq.org 2011-11-04 16:31:48 CDT --- (In reply to comment #9)
So it's actually surprising we don't see random crashes from that thread when winmm is forcefully unloaded when the app exits.
Libraries are of course not unloaded at exit time, that would be pointless.
-
wine-bugs＠winehq.org