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.