Ok so it's crashing nowhere in particular during normal operation, would it be possible to get a complete backtrace from the assertion failure?
Printable View
Ok so it's crashing nowhere in particular during normal operation, would it be possible to get a complete backtrace from the assertion failure?
To get a useful backtrace for you, I compiled wine myself.
So here is the backtrace:
While experimenting with the bug I encountered several crashes at totally different code sections within wine.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
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:
In dsound/mixer.c:663 there is a memset which clears the buffers that are returned by the IAudioRenderClient_GetBuffer() function.Code:fixme:pulse:AudioClient_Initialize TMP Buffer 0x1327b350 alloced. Size 73728
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.
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.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
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
So it seems to me there is a major disagreement between dsound and the winepulse driver how large the playback buffers are.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)
Hopefully this post will help you to find the cause of the problem.
Falk
Yeehaaa I finally was able to fix the problem.
The Problem is that dsound requests a padded Wave format, which is not supported by the winepulse driver. But the driver accepts it without any problem which results in trashing the heap.
To fix it just add the following lines to the mmdevdrv.c in the function AudioClient_IsFormatSupported() directly before the "if (hr == S_OK || !out)"
Furthermore I would recommend to improve the checks for the supplied wave format in the AudioClient_Initialize function, to catch all formats that are not supported by pulseaudio.Code://No padding in the samples allowed!!
if((fmt->nChannels * fmt->wBitsPerSample)/8 != fmt->nBlockAlign)
{
FIXME("Unsupported padded Sample format requested");
hr = S_FALSE;
}
Falk
Where can I find this mmdevdrv.c file to add these lines?
Oh.. derp
Have a patch:
Code:diff --git a/dlls/dsound/primary.c b/dlls/dsound/primary.c
index 981fc02..a1056f0 100644
--- a/dlls/dsound/primary.c
+++ b/dlls/dsound/primary.c
@@ -157,7 +157,11 @@ static WAVEFORMATEX *DSOUND_WaveFormat(DirectSoundDevice *device, IAudioClient *
static int once;
if (!once++)
FIXME("Limiting channels to 2 due to lack of multichannel support\n");
- mixwfe->Format.nChannels = 2;
+
+ w = &mixwfe->Format;
+ w->nChannels = 2;
+ w->nBlockAlign = w->nChannels * w->wBitsPerSample / 8;
+ w->nAvgBytesPerSec = w->nSamplesPerSec * w->nBlockAlign;
}
if (!IsEqualGUID(&mixwfe->SubFormat, &KSDATAFORMAT_SUBTYPE_IEEE_FLOAT)) {
Can you test the next patch too without the dsound patch?
Both patches should fix the issue, but I want to see if both patches fix the same issue first.
Code:commit 756e43bfeb8b4aee34a1427d38abca38dfae5d62
Author: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Date: Mon Nov 12 17:15:49 2012 +0100
winepulse: fix the checks in IsFormatSupported
Thanks to DGhost001 for reporting and isolating the issue.
diff --git a/dlls/winepulse.drv/mmdevdrv.c b/dlls/winepulse.drv/mmdevdrv.c
index 643d55e..86dd10a 100644
--- a/dlls/winepulse.drv/mmdevdrv.c
+++ b/dlls/winepulse.drv/mmdevdrv.c
@@ -1443,6 +1443,10 @@ static HRESULT WINAPI AudioClient_IsFormatSupported(IAudioClient *iface,
}
}
+ if (fmt->nBlockAlign != fmt->nChannels * fmt->wBitsPerSample / 8 ||
+ fmt->nAvgBytesPerSec != fmt->nBlockAlign * fmt->nSamplesPerSec)
+ hr = S_FALSE;
+
if (hr == S_OK || !out) {
CoTaskMemFree(closest);
if (out)
I can confirm both patches are fixing the problem independent from each other.
But the first patch also fixes the static noise I got, while using the a52 pulse audio sink with my and your second patch.
For Analog 5.1 output both patches make no difference, and both work.
@Nilladar
You find the mentioned file in the ubuntu wine source under dlls/winepulse.drv/mmdevdrv.c. But before you start compiling wine yourself, just wait I hope there will be an update soon as it is now know how to fix the problem.
Falk
Oh I was in fact hit by this, but valgrind wasn't enabled on the wine ppa so I didn't get warned about it. Probably why steam and steam games didn't work for me on the -rt kernel.
Some more digging, it seems I broke things most likely a long time ago when I originally reworked IsFormatSupported when I still had hope it could be included into wine. Sadly none of the tests in mmdevapi exposes the bug, and other drivers look affected too.
I guess I'll wait it out before I go recompile wine. Either way, nice work on the solve.
wine1.5 - 1.5.17-0ubuntu4 uploaded, should be fixed there. I pushed it to multimedia.git too, hopefully someone watches that so that other distros can pick it up. :)