[Bug 28388] New: winmm/midi.ok deadlocks and crashes occasionally?
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(a)winehq.org ReportedBy: dank(a)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 -- 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=28388 --- Comment #1 from Dan Kegel <dank(a)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. -- 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=28388 --- Comment #2 from Dan Kegel <dank(a)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... -- 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=28388 Raymond <superquad.vortex2(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |superquad.vortex2(a)gmail.com --- Comment #3 from Raymond <superquad.vortex2(a)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. -- 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=28388 --- Comment #4 from Dan Kegel <dank(a)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. -- 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=28388 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t --- Comment #5 from Jörg Höhle <hoehle(a)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. -- 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=28388 --- Comment #6 from Dan Kegel <dank(a)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. -- 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=28388 --- Comment #7 from Dan Kegel <dank(a)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?) -- 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=28388 --- Comment #8 from Dan Kegel <dank(a)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. -- 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=28388 --- Comment #9 from Jörg Höhle <hoehle(a)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). -- 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=28388 --- Comment #10 from Dan Kegel <dank(a)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.) -- 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=28388 --- Comment #11 from Dan Kegel <dank(a)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. -- 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=28388 --- Comment #12 from Dan Kegel <dank(a)kegel.com> 2011-10-01 09:36:34 CDT --- Oh, and I'm just using stock ubuntu, pulseaudio and all. -- 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=28388 --- Comment #13 from Raymond <superquad.vortex2(a)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)) -- 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=28388 --- Comment #14 from Jörg Höhle <hoehle(a)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. -- 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=28388 --- Comment #15 from Jörg Höhle <hoehle(a)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... -- 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=28388 --- Comment #16 from Jörg Höhle <hoehle(a)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. -- 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=28388 Bruni <earns.61(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |earns.61(a)gmail.com --- Comment #17 from Bruni <earns.61(a)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 -- 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=28388 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard(a)winehq.org --- Comment #18 from Jörg Höhle <hoehle(a)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. -- 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=28388 --- Comment #19 from Alexandre Julliard <julliard(a)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. -- 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=28388 --- Comment #20 from Bruni <earns.61(a)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/ -- 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=28388 --- Comment #21 from Dan Kegel <dank(a)kegel.com> 2012-01-20 09:04:17 CST --- *** Bug 28265 has been marked as a duplicate of this bug. *** -- 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=28388 --- Comment #22 from Jörg Höhle <hoehle(a)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. -- 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=28388 --- Comment #23 from Dan Kegel <dank(a)kegel.com> 2012-02-07 00:02:45 CST --- The patch passed several hours of testing with midi.ok, seems fine here. -- 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=28388 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #24 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2012-02-17 12:11:22 CST --- Fixed by commit 1b1157600539b1d0e263f707b34b3c4d7e58d99c -- 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=28388 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |1b1157600539b1d0e263f707b34 | |b3c4d7e58d99c -- 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=28388 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #25 from Alexandre Julliard <julliard(a)winehq.org> 2012-02-17 13:50:31 CST --- Closing bugs fixed in 1.4-rc4. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=28388 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net Component|-unknown |winmm&mci -- 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