To get a useful backtrace for you, I compiled wine myself.
So here is the backtrace:
Code:
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:f77d9425 ESP:1aefe66c EBP:000019cb EFLAGS:00000202( - -- I - - - )
EAX:00000000 EBX:0000195e ECX:000019cb EDX:00000006
ESI:737d1000 EDI:f7623ff4
Stack dump:
0x1aefe66c: 7bd01aa4 f74ac1df f7623ff4 1aefe7a0
0x1aefe67c: f74af825 00000006 1aefe720 00000000
0x1aefe68c: 00000000 00000000 7bd02ea8 f7624440
0x1aefe69c: 00000028 00000000 00000000 00000000
0x1aefe6ac: 7c1d3d64 7bd004b8 000000fe 7c16cc90
0x1aefe6bc: 7c1ede00 00000001 00000028 1aefe708
Backtrace:
=>0 0xf77d9425 __kernel_vsyscall+0x5() in [vdso].so (0x000019cb)
1 0xf74ac1df gsignal+0x4e() in libc.so.6 (0x7bd01aa4)
2 0xf74af825 abort+0x174() in libc.so.6 (0x7bd01aa4)
3 0x7c17513c pa_memblock_unref+0x32b() in libpulsecommon-2.0.so (0x7bd01aa4)
4 0x7c176a50 pa_memexport_process_release+0xef() in libpulsecommon-2.0.so (0x7bd01aa4)
5 0x7c181fea in libpulsecommon-2.0.so (+0x34fe9) (0x7bd005d0)
6 0x7c16cd58 in libpulsecommon-2.0.so (+0x1fd57) (0x00000000)
7 0x7c1d5495 pa_mainloop_dispatch+0x104() in libpulse.so.0 (0x00000000)
8 0x7c1d5973 pa_mainloop_iterate+0x52() in libpulse.so.0 (0x1aefea18)
9 0x7c1d5a44 pa_mainloop_run+0x33() in libpulse.so.0 (0x1aefea18)
10 0x7c64f249 pulse_mainloop_thread+0x68(tmp=0x0(nil)) [/wine-1.5.16/dlls/winepulse.drv/mmdevdrv.c:274] in winepulse (0x1aefea18)
11 0x7bc75a00 call_thread_func_wrapper+0xb() in ntdll (0x1aefea28)
12 0x7bc7882d call_thread_func+0x7c(entry=0x7c64f1e0, arg=0x0(nil), frame=0x1aefeb18) [/wine-1.5.16/dlls/ntdll/signal_i386.c:2522] in ntdll (0x1aefeaf8)
13 0x7bc759de call_thread_entry_point+0x11() in ntdll (0x1aefeb18)
14 0x7bc7e8d9 start_thread+0xe8(info=0x7ff5cfb8) [/wine-1.5.16/dlls/ntdll/thread.c:408] in ntdll (0x1aeff368)
15 0xf762fd4c start_thread+0xcb() in libpthread.so.0 (0x1aeff468)
0xf77d9425 __kernel_vsyscall+0x5 in [vdso].so: movl $0x2b,%ecx
While experimenting with the bug I encountered several crashes at totally different code sections within wine.
So I started reading your code and added some additional debug output to it. And I found something very interesting which would be a very good explanation for the crash.
To the AudioClient_Initialize function I added an output to tell me how large the temporary buffer (which get handed out if pulse has not enough free frames available) is in the moment of its allocation.
And I got the following:
Code:
fixme:pulse:AudioClient_Initialize TMP Buffer 0x1327b350 alloced. Size 73728
In dsound/mixer.c:663 there is a memset which clears the buffers that are returned by the IAudioRenderClient_GetBuffer() function.
Exactly there I added also an additional debug output the see if the size of the memset matches the size of the allocation for the buffer.
Code:
fixme:pulse:AudioRenderClient_GetBuffer 0x1327b150 Not using pulse locked data: 0 8187/9216 0/9216
fixme:dsound:DSOUND_PerformMix Buffer 0x1327b350 cleared. Frames 9216 221184
The last number in the last line is the number of bytes that get actually cleared by the memset. If you compare that to the alloced size of the tmp buffer you see that there are a alot of bytes written behind the tmp_buffer.
This phenomena is not limited to the tmp_buffer.
If the tmp_buffer gets not handed out on the first request then wine is crashing within the pulse library. If the tmp_buffer is handed out than the crash most likely occurs within dsound due to trashed function pointers.
An typical backtrace than looks like this
Code:
Register dump:
CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b
EIP:7e186f3d ESP:0231ebbc EBP:0231ec94 EFLAGS:00010246( R- -- I Z- -P- )
EAX:1328d398 EBX:7e1afff4 ECX:13279518 EDX:00000000
ESI:13279518 EDI:00000000
Stack dump:
0x0231ebbc: 1328d398 0231ec78 0231ed04 7bc484ae
0x0231ebcc: 7bc37091 0231ec48 0231ec94 7bc37091
0x0231ebdc: 7bc3715f 0006d1b8 0231ec34 7bc3715f
0x0231ebec: 7bc37091 132795c4 1327b0d0 0231ed04
0x0231ebfc: 7bc3715f 13121000 7e19975c 0231ed40
0x0231ec0c: 7bcb7ff4 132795c4 7bcb7ff4 0231ec38
Backtrace:
=>0 0x7e186f3d DirectSoundDevice_CreateSoundBuffer+0x57d(device=0x13279518, dsbd=0x231ed04, ppdsb=0x139f0678, lpunk=(nil), from8=0) [/wine-1.5.16/dlls/dsound/dsound.c:927] in dsound (0x0231ec94)
1 0x7e1873f6 IDirectSound8Impl_CreateSoundBuffer+0x95(iface=0x132794f4, dsbd=0x231ed04, ppdsb=0x139f0678, lpunk=(nil)) [/wine-1.5.16/dlls/dsound/dsound.c:243] in dsound (0x0231ece4)
2 0x00a20c3e in dead space (+0x620c3d) (0x010c1894)
0x7e186f3d DirectSoundDevice_CreateSoundBuffer+0x57d [/wine-1.5.16/dlls/dsound/dsound.c:927] in dsound: call *0x4(%edx)
So it seems to me there is a major disagreement between dsound and the winepulse driver how large the playback buffers are.
Hopefully this post will help you to find the cause of the problem.
Falk
Bookmarks