[Bug 28597] New: winecfg page fault during sound test
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(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk CC: aeikum(a)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(a)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 -- 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=28597 Andrew Eikum <aeikum(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|trivial |normal --- Comment #1 from Andrew Eikum <aeikum(a)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. -- 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=28597 Ken Sharp <kennybobs(a)o2.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|programs |winmm&mci -- 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=28597 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t --- Comment #2 from Jörg Höhle <hoehle(a)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. -- 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=28597 --- Comment #3 from Ken Sharp <kennybobs(a)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. -- 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=28597 --- Comment #4 from Andrew Eikum <aeikum(a)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. -- 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=28597 --- Comment #5 from Jörg Höhle <hoehle(a)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). -- 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=28597 --- Comment #6 from Andrew Eikum <aeikum(a)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. -- 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=28597 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |00629cb0b3c7c3b25d8ccbfc567 | |55344dc9a1e89 Status|NEW |RESOLVED CC| |adys.wh(a)gmail.com Resolution| |FIXED --- Comment #7 from Jerome Leclanche <adys.wh(a)gmail.com> 2011-10-28 14:18:53 CDT --- Should be fixed by 00629cb0b3c7c3b25d8ccbfc56755344dc9a1e89 -- 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=28597 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #8 from Alexandre Julliard <julliard(a)winehq.org> 2011-11-04 14:14:24 CDT --- Closing bugs fixed in 1.3.32. -- 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=28597 --- Comment #9 from Jörg Höhle <hoehle(a)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. -- 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=28597 --- Comment #10 from Alexandre Julliard <julliard(a)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. -- 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