http://bugs.winehq.org/show_bug.cgi?id=28388
Summary: winmm/midi.ok deadlocks and crashes occasionally? Product: Wine Version: 1.3.28 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: dank@kegel.com
I saw this today on my a8-3850 (on the first, but not second, buildbot run):
../../../tools/runtest -q -P wine -M winmm.dll -T ../../.. -p winmm_test.exe.so midi.c && touch midi.ok fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 32 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 6 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 32 channels, pretending there's only 2 channels fixme:mixer:ALSA_MixerInit No master control found on HD-Audio Generic, disabling mixer fixme:mci:MCI_SysInfo Don't know how to get # of MCI devices of a given type err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 003e, blocked by 002e, retrying (60 sec) wine: Critical section 00110060 wait failed at address 0x7bc34357 (thread 003e), starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 003e, blocked by 002e, retrying (60 sec) err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x7bc34357 Command exited with non-zero status 148
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #1 from Dan Kegel dank@kegel.com 2011-09-15 09:05:53 CDT --- I've seen this twice in 30 builds on my a8-3850 machine, and once earlier on a different machine, so it's at least somewhat repeatable.
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #2 from Dan Kegel dank@kegel.com 2011-09-19 16:07:01 CDT --- Saw it this time on my i7 with WINEDEBUG=warn+heap.
os: Ubuntu 10.04.3 LTS, 2.6.32-33-generic, pulseaudio 0.9.21-63-gd3efa-dirty, Advanced Linux Sound Architecture Driver Version 1.0.21. ram: 3212 MB cpu: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz gpu: GeForce GT 240/PCI/SSE2 3.2.0 NVIDIA 195.36.24
Three strikes and you're out. This is now blacklisted for the buildbot, http://code.google.com/p/winezeug/source/browse/trunk/buildbot/dotests_black...
http://bugs.winehq.org/show_bug.cgi?id=28388
Raymond superquad.vortex2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |superquad.vortex2@gmail.com
--- Comment #3 from Raymond superquad.vortex2@gmail.com 2011-09-20 19:30:00 CDT --- it still work on 1.3.28
seem like you have not load seq_dummy if you did not have any midi device
./wine dlls/winmm/tests/winmm_test.exe.so midi
fixme:service:scmdatabase_autostart_services Auto-start service L"DXDebug" failed to start: 2 fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 32 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 8 channels, pretending there's only 2 channels fixme:alsa:AudioClient_GetMixFormat Don't know what to do with 32 channels, pretending there's only 2 channels midi.c:181: Found 1 MIDI IN devices midi.c:183: ** Testing device 0 midi.c:117: * Midi Through Port-0: manufacturer=255, product=1, support=0 midi.c:128: Message 3c1, wParam=8000, lParam=0 from midiInOpen midi.c:144: MIDIHDR flags=0 when unsent midi.c:155: Message 3c2, wParam=8000, lParam=0 from midiInClose midi.c:187: ** Testing MIDI mapper midi.c:739: Found 3 MIDI OUT devices fixme:mci:MCI_SysInfo Don't know how to get # of MCI devices of a given type midi.c:200: Found 1 MCI sequencer devices midi.c:747: ** Testing device 0 midi.c:222: * OPL3 FM synth - OPL3 FM Port: manufacturer=255, product=1, tech=2, support=3: 16 voices, 16 notes midi.c:244: Message 3c7, wParam=8000, lParam=0 from midiOutOpen midi.c:250: Current volume ffffffff on device 0 midi.c:286: ShortMsg type 93 midi.c:311: MIDIHDR flags=0 when unsent midi.c:327: Message 3c8, wParam=8000, lParam=0 from midiOutClose midi.c:417: Message 3c7, wParam=8000, lParam=0 from midiStreamOpen midi.c:427: Test failed: default stream time division 480 midi.c:450: MIDIHDR flags=e when submitted midi.c:467: async MIDI still queued midi.c:479: Message 3ca, wParam=8000, lParam=32fc70 from midiStream callback midi.c:480: Message 3c9, wParam=8000, lParam=32fc70 from midiStreamOut midi.c:490: MIDIHDR stream flags=9 when finished midi.c:354: Stream position 0ms midi.c:357: Stream position 0 ticks fixme:winmm:midiStreamPosition Unsupported time type 10 midi.c:351: Test failed: midiStreamPosition type 10 converted to 1 rc=MMSYSERR_NOERROR midi.c:354: Stream position 0ms fixme:winmm:midiStreamPosition Unsupported time type 8 midi.c:354: Stream position 0ms midi.c:354: Stream position 0ms midi.c:354: Stream position 0ms midi.c:527: buffer: 24 midi.c:539: Message 3c9, wParam=8000, lParam=32fc70 from midiStreamOut midi.c:555: Message 3ca, wParam=8000, lParam=32fc70 from 1 of 2 events midi.c:556: Message 3c9, wParam=8000, lParam=32fc70 from 1 of 2 events midi.c:566: Message 3ca, wParam=8000, lParam=32fc70 from 2 of 2 events midi.c:567: Message 3ca, wParam=8000, lParam=32fc70 from 2 of 2 events midi.c:568: Message 3c9, wParam=8000, lParam=32fc70 from 2 of 2 events midi.c:579: Message 3c9, wParam=8000, lParam=32fc70 from 0 CB in 2 events midi.c:612: Test failed: midiOutPrepare stream too large rc=MMSYSERR_NOERROR midi.c:622: Message 3c8, wParam=8000, lParam=0 from midiStreamClose midi.c:628: Device 0 accepts NULL CALLBACK_FUNCTION midi.c:747: ** Testing device 1 midi.c:222: * OPL3 FM synth - OPL3 OSS Port: manufacturer=255, product=1, tech=1, support=0: 0 voices, 0 notes midi.c:241: Test failed: midiOutOpen(dev=1) rc=MMSYSERR_NOTENABLED midi.c:414: Test failed: midiStreamOpen(dev=1) rc=MMSYSERR_ALLOCATED midi.c:747: ** Testing device 2 midi.c:222: * Midi Through Port-0: manufacturer=255, product=1, tech=1, support=0: 0 voices, 0 notes midi.c:244: Message 3c7, wParam=8000, lParam=0 from midiOutOpen midi.c:286: ShortMsg type 93 midi.c:311: MIDIHDR flags=0 when unsent midi.c:327: Message 3c8, wParam=8000, lParam=0 from midiOutClose midi.c:417: Message 3c7, wParam=8000, lParam=0 from midiStreamOpen midi.c:427: Test failed: default stream time division 480 midi.c:450: MIDIHDR flags=e when submitted midi.c:467: async MIDI still queued midi.c:479: Message 3ca, wParam=8000, lParam=32fc70 from midiStream callback midi.c:480: Message 3c9, wParam=8000, lParam=32fc70 from midiStreamOut midi.c:490: MIDIHDR stream flags=9 when finished midi.c:354: Stream position 0ms midi.c:357: Stream position 0 ticks fixme:winmm:midiStreamPosition Unsupported time type 10 midi.c:351: Test failed: midiStreamPosition type 10 converted to 1 rc=MMSYSERR_NOERROR midi.c:354: Stream position 0ms fixme:winmm:midiStreamPosition Unsupported time type 8 midi.c:354: Stream position 0ms midi.c:354: Stream position 0ms midi.c:354: Stream position 0ms midi.c:527: buffer: 24 midi.c:539: Message 3c9, wParam=8000, lParam=32fc70 from midiStreamOut midi.c:555: Message 3ca, wParam=8000, lParam=32fc70 from 1 of 2 events midi.c:556: Message 3c9, wParam=8000, lParam=32fc70 from 1 of 2 events midi.c:566: Message 3ca, wParam=8000, lParam=32fc70 from 2 of 2 events midi.c:567: Message 3ca, wParam=8000, lParam=32fc70 from 2 of 2 events midi.c:568: Message 3c9, wParam=8000, lParam=32fc70 from 2 of 2 events midi.c:579: Message 3c9, wParam=8000, lParam=32fc70 from 0 CB in 2 events midi.c:612: Test failed: midiOutPrepare stream too large rc=MMSYSERR_NOERROR midi.c:622: Message 3c8, wParam=8000, lParam=0 from midiStreamClose midi.c:628: Device 2 accepts NULL CALLBACK_FUNCTION midi.c:756: ** Testing MIDI mapper midi.c:222: * Wine midi mapper: manufacturer=255, product=1, tech=5, support=3: 0 voices, 0 notes midi.c:244: Message 3c7, wParam=8000, lParam=0 from midiOutOpen midi.c:250: Current volume ffffffff on device -1 midi.c:286: ShortMsg type 93 midi.c:311: MIDIHDR flags=0 when unsent midi.c:327: Message 3c8, wParam=8000, lParam=0 from midiOutClose midi.c:417: Message 3c7, wParam=8000, lParam=0 from midiStreamOpen midi.c:427: Test failed: default stream time division 480 midi.c:450: MIDIHDR flags=e when submitted midi.c:467: async MIDI still queued midi.c:479: Message 3ca, wParam=8000, lParam=32fc70 from midiStream callback midi.c:480: Message 3c9, wParam=8000, lParam=32fc70 from midiStreamOut midi.c:490: MIDIHDR stream flags=9 when finished midi.c:354: Stream position 0ms midi.c:357: Stream position 0 ticks fixme:winmm:midiStreamPosition Unsupported time type 10 midi.c:351: Test failed: midiStreamPosition type 10 converted to 1 rc=MMSYSERR_NOERROR midi.c:354: Stream position 0ms fixme:winmm:midiStreamPosition Unsupported time type 8 midi.c:354: Stream position 0ms midi.c:354: Stream position 0ms midi.c:354: Stream position 0ms midi.c:527: buffer: 24 midi.c:539: Message 3c9, wParam=8000, lParam=32fc70 from midiStreamOut midi.c:555: Message 3ca, wParam=8000, lParam=32fc70 from 1 of 2 events midi.c:556: Message 3c9, wParam=8000, lParam=32fc70 from 1 of 2 events midi.c:566: Message 3ca, wParam=8000, lParam=32fc70 from 2 of 2 events midi.c:567: Message 3ca, wParam=8000, lParam=32fc70 from 2 of 2 events midi.c:568: Message 3c9, wParam=8000, lParam=32fc70 from 2 of 2 events midi.c:579: Message 3c9, wParam=8000, lParam=32fc70 from 0 CB in 2 events midi.c:612: Test failed: midiOutPrepare stream too large rc=MMSYSERR_NOERROR midi.c:622: Message 3c8, wParam=8000, lParam=0 from midiStreamClose midi.c:628: Device -1 accepts NULL CALLBACK_FUNCTION midi: 386 tests executed (0 marked as todo, 11 failures), 0 skipped.
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #4 from Dan Kegel dank@kegel.com 2011-09-20 20:00:53 CDT --- Please don't paste long logs, attach them instead.
This error does not happen often or on all systems, so it doesn't really help to know that it works ok for you.
http://bugs.winehq.org/show_bug.cgi?id=28388
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle@users.sourceforge.ne | |t
--- Comment #5 from Jörg Höhle hoehle@users.sourceforge.net 2011-09-26 14:20:38 CDT --- Please attach a Valgrind log of when it hangs. Better with the CloseDriver hack http://wiki.winehq.org/Wine_and_Valgrind#head-36cfebf2fe3a5153e58d8d44085402... A "bt all" with line numbers may be another starting point.
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #6 from Dan Kegel dank@kegel.com 2011-09-29 00:07:30 CDT --- I ran the test in a loop; after about 200 runs, on two different machines, it hit the problem. I got lucky and was there when it happend once, and did btall, which gave a good backtrace for one of the two threads involved in the deadlock:
=>0 HEAP_FindFreeBlock+0x49(heap=0x110000, size=0x100, ppSubHeap=0x73e53c) [dlls/ntdll/heap.c:990] 1 RtlAllocateHeap+0x1fd(heap=0x110000, flags=0x2, size=0x100) [dlls/ntdll/heap.c:1675] 2 peek_message+0x84(msg=0x73e9d0, hwnd=(nil), first=0, last=0, flags=0x4ff0001, changed_mask=0x4ff) [dlls/user32/message.c:2612] 3 GetMessageW+0x151(msg=0x73e9d0, hwnd=(nil), first=0, last=0) [dlls/user32/message.c:3610] 4 GetMessageA+0x5f(msg=0x73e9d0, hwnd=(nil), first=0, last=0) [dlls/user32/message.c:3625] 5 MMSYSTEM_MidiStream_Player+0x132(pmt=0x129328) [dlls/winmm/winmm.c:1155] 6 call_thread_func+0xb()
The other thread didn't have a backtrace, all it showed was that it was in a linux system call.
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #7 from Dan Kegel dank@kegel.com 2011-09-29 19:58:56 CDT --- Happened again on my e7300 (after 26000 tries!), and I happened to be there again. Log:
err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 0045, blocked by 0026, retrying (60 sec) wine: Critical section 00110060 wait failed at address 0x7bc34357 (thread 0045), starting debugger...
Here's what btall said; it's very similar to the last time one.
Backtracing for thread 0026 in process 0016 (Z:\home\dank\wine-git\dlls\winmm\tests\winmm_test.exe): Backtrace: =>0 notify_alloc+0x10(ptr=0x137b48, size=0x100, init=0) [dlls/ntdll/heap.c:254] 1 RtlAllocateHeap+0x32c(heap=0x110000, flags=0x2, size=0x100) [dlls/ntdll/heap.c:1702] 2 peek_message+0x84(msg=0x73e9d0, hwnd=(nil), first=0, last=0, flags=0x4ff0001, changed_mask=0x4ff) [dlls/user32/message.c:2612] 3 GetMessageW+0x151(msg=0x73e9d0, hwnd=(nil), first=0, last=0) [dlls/user32/message.c:3610] 4 GetMessageA+0x5f(msg=0x73e9d0, hwnd=(nil), first=0, last=0) [dlls/user32/message.c:3625] 5 MMSYSTEM_MidiStream_Player+0x132(pmt=0x129328) [dlls/winmm/winmm.c:1155] ...
Backtracing for thread 0045 in process 0016 (Z:\home\dank\wine-git\dlls\winmm\tests\winmm_test.exe): Backtrace: =>0 0x68000832 GLIBC_2+0x832() in ld-linux.so.2 (0x00000000) 0x68000830 GLIBC_2+0x830 in ld-linux.so.2: int $0x80
(I doubt this is the cause, but isn't that PeekMessage loop in MMSYSTEM_MidiStream_Player() kind of busy?)
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #8 from Dan Kegel dank@kegel.com 2011-09-29 20:46:09 CDT --- With WINEDEBUG=warn+heap, it happens a lot sooner (first run: first try; second run: sixth try). Still seeing the same thing: a deadlock between the thread running MMSYSTEM_MidiStream_Player(), which is always somewhere in RtlAllocateHeap in peek_message, and another thread without a stack.
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #9 from Jörg Höhle hoehle@users.sourceforge.net 2011-10-01 03:48:06 CDT --- Not seen here in 1841 iterations overnight, judging from runtest's $? = 0 return code (without logs). Ubuntu Intrepid, wine-1.3.29, warn+heap, no PulseAudio, Timidity restarted so as to grab ALSA's dmix instead of PA.
but isn't that PeekMessage loop in MMSYSTEM_MidiStream_Player() kind of busy?
As the comment says, it's there to drain all messages. The wait happens in start_header: GetMessage. `top` shows that Timidity is busy, not Wine, so I see no indication of a busy loop. I'm still not familiar enough with windows messages to tell whether PeekMessage is superfluous and goto start_header -> GetMessage would be enough, i.e. GetMessage will return old message.
Another interesting input would be: what did the tests do when the issue arises? Perhaps WINETEST_REPORT_SUCCESS would show it's always at the same test.
What does Valgrind have to say? I'm asking because a time out in a critical section may be misleading, because it's often enough a consequence of an earlier trouble (like audio underruns occurring after the app's main thread crashed).
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #10 from Dan Kegel dank@kegel.com 2011-10-01 09:16:04 CDT --- Created attachment 36628 --> http://bugs.winehq.org/attachment.cgi?id=36628 logs with env WINETEST_REPORT_SUCCESS=1 WINEDEBUG=heap+warn,+winmm
OK, here are four failing logs with WINETEST_REPORT_SUCCESS=1. Commenting out the call to test_midi_infns() didn't seem to reduce the frequency of crashes, so I did that to make the logs shorter. Happily, setting +winmm also didn't affect anything. (I'll see if I can get a valgrind run later.)
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #11 from Dan Kegel dank@kegel.com 2011-10-01 09:26:50 CDT --- Created attachment 36629 --> http://bugs.winehq.org/attachment.cgi?id=36629 valgrind log
There is one possible wild pointer reference buried in an ioctl in snd_ctl_pcm_info in alsa_get_card_devices (mmdevdrv.c:319), see attached log.
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #12 from Dan Kegel dank@kegel.com 2011-10-01 09:36:34 CDT --- Oh, and I'm just using stock ubuntu, pulseaudio and all.
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #13 from Raymond superquad.vortex2@gmail.com 2011-10-10 20:48:45 CDT --- (In reply to comment #0)
fixme:mci:MCI_SysInfo Don't know how to get # of MCI devices of a given type
when "winetest midi" in xp, it found 1 MCI sequencer devices but wine's mci (e.g. winealsa) still unable to find the sequencer
midi.c:181: Found 1 MIDI IN devices
.. midi.c:739: Found 4 MIDI OUT devices
midi.c:200: Found 1 MCI sequencer devices
still unable to play music(midi) in pinball since mcidrivers is null
trace:mci:mciSendCommandA (00000000, MCI_OPEN, 00002002, 0102500c) trace:mci:mciSendCommandW (00000000, MCI_OPEN, 00002002, 00140fe4) trace:mci:MCI_Open (00002002, 0x140fe4) trace:mci:MCI_Open devType=L"pinball.mid" ! trace:mci:MCI_LoadMciDriver wDevID=0001 fixme:mci:MCI_LoadMciDriver Couldn't load driver for type L"PINBALL.MID". trace:mci:mciSendCommandW => 00000132 trace:mci:MCI_Close (ffffffff, 00000002, (nil))
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #14 from Jörg Höhle hoehle@users.sourceforge.net 2011-10-27 03:25:20 CDT --- We don't know what causes the bug. From Dan's logs: - it always occurs after midiStreamOpen (past test line 414); - there's never a backtrace for the main winmm thread (running the test), which may indicate some stack corruption; - mark_block_free within AllocateHeap is a strange place to hang, as it's just a loop, except perhaps if size overflowed to MAX_INT and it's overwriting all memory.
wild pointer reference buried in an ioctl in snd_ctl_pcm_info
I think we can ignore that here.
Somebody should examine closely and understand how winmm starts the MMSYSTEM_MidiStream_Player thread and esp. how it creates its message port: 1140 /* force thread's queue creation */ 1141 PeekMessageA(&msg, 0, 0, 0, PM_NOREMOVE); but actually Dan found the hang later in: 1154 /* for first message, block until one arrives, then process all that are available */ 1155 GetMessageA(&msg, 0, 0, 0);
May the custom WINE_MSM_HEADER/STOP messages cause serialization/pointer issues?
Or we "simply" have a case of buffer overflow that destroys the heap arena information, leading to a deadlock. Oddly, warn+heap makes no difference.
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #15 from Jörg Höhle hoehle@users.sourceforge.net 2011-10-27 14:54:35 CDT --- What if you comment out the call to SuspendThread in midiStreamOpen? Yet that does not explain the lack of a backtrace of the one thread...
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #16 from Jörg Höhle hoehle@users.sourceforge.net 2011-10-28 00:29:08 CDT --- The single core Ubuntu laptop never crashes even after several thousand iterations, but the dual core Mac with MacOS did with warn+heap at iteration 106 with a log like yours in comment #0:
fixme:mci:MCI_SysInfo Don't know how to get # of MCI devices of a given type fixme:wave:AudioUnit_GetVolume independent left/right volume not implemented err:wave:AudioUnit_GetVolume AudioUnitGetParameter return an error -10866 err:wave:AudioUnit_GetVolume AudioUnitGetParameter return an error -10866 fixme:winmm:midiStreamPosition Unsupported time type 10 fixme:winmm:midiStreamPosition Unsupported time type 8 err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 003b, blocked by 0039, retrying (60 sec) wine: Critical section 00110060 wait failed at address 0x7bc28aa9 (thread 003b), starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main process heap section" wait timed out in thread 003b, blocked by 0039, retrying (60 sec) err:seh:raise_exception Unhandled exception code c0000194 flags 0 addr 0x7bc28aa9
No debugger, no backtrace.
http://bugs.winehq.org/show_bug.cgi?id=28388
Bruni earns.61@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |earns.61@gmail.com
--- Comment #17 from Bruni earns.61@gmail.com 2011-10-28 11:57:06 CDT --- @Jörg I'm just being curious, does this lead to correct results when you compare a single core Ubuntu and a dual core Mac anyway? What if to make the Mac utilize only one core WINEDEBUG=warn+heap,+winmm schedtool -a 0x2 -e wine ~/.wine/drive_c/midi_app.exe
http://bugs.winehq.org/show_bug.cgi?id=28388
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org
--- Comment #18 from Jörg Höhle hoehle@users.sourceforge.net 2011-10-29 16:42:03 CDT --- No schedtool here on my MacOS. Where does that come from? Looks like Linux only.
No deadlock in >4300 iterations on MacOS after SuspendThread commented out (of course this causes test failures).
Everyone will argue that SuspendThread is bad design anyway, but I'd expect that function to either prevent scheduling that thread or to pause outside system level code, not to freeze it while executing system (ntdll heap management) code. MSDN says "to stop executing user-mode (application) code". Does that indicate a bug with SIGUSR1 handling in Wine?
Regardless of a possible bug in Wine's handling of thread suspension, the MIDI player ought to be changed such that midiStreamRestart and Pause do not depend on SuspendThread. Beside winmm:midi, only qcap:v4l uses that.
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #19 from Alexandre Julliard julliard@winehq.org 2011-10-29 17:11:23 CDT --- (In reply to comment #18)
Everyone will argue that SuspendThread is bad design anyway, but I'd expect that function to either prevent scheduling that thread or to pause outside system level code, not to freeze it while executing system (ntdll heap management) code. MSDN says "to stop executing user-mode (application) code". Does that indicate a bug with SIGUSR1 handling in Wine?
No, SuspendThread can suspend anywhere, including inside a lock. There's essentially no safe way to use it. Any design that relies on it is broken.
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #20 from Bruni earns.61@gmail.com 2011-10-31 02:49:11 CDT --- (In reply to comment #18)
No schedtool here on my MacOS. Where does that come from? Looks like Linux only.
Do you have macports installed? http://her.gr.distfiles.macports.org/mirrors/linux/pld/pool/s/schedtool/
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #21 from Dan Kegel dank@kegel.com 2012-01-20 09:04:17 CST --- *** Bug 28265 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #22 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-06 11:56:50 CST --- Created attachment 38721 --> http://bugs.winehq.org/attachment.cgi?id=38721 MIDIStream player without SuspendThread
Dan, please test this patch thoroughly. I'll be on a dual-core machine next week only, that was the only machine where I could reproduce the issue.
http://bugs.winehq.org/show_bug.cgi?id=28388
--- Comment #23 from Dan Kegel dank@kegel.com 2012-02-07 00:02:45 CST --- The patch passed several hours of testing with midi.ok, seems fine here.
http://bugs.winehq.org/show_bug.cgi?id=28388
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #24 from Jörg Höhle hoehle@users.sourceforge.net 2012-02-17 12:11:22 CST --- Fixed by commit 1b1157600539b1d0e263f707b34b3c4d7e58d99c
http://bugs.winehq.org/show_bug.cgi?id=28388
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |1b1157600539b1d0e263f707b34 | |b3c4d7e58d99c
http://bugs.winehq.org/show_bug.cgi?id=28388
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Alexandre Julliard julliard@winehq.org 2012-02-17 13:50:31 CST --- Closing bugs fixed in 1.4-rc4.
https://bugs.winehq.org/show_bug.cgi?id=28388
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Component|-unknown |winmm&mci
-
wine-bugs＠winehq.org