[Bug 40963] New: Upward, lonely robot Demo crashes with Too many buffers queued
https://bugs.winehq.org/show_bug.cgi?id=40963 Bug ID: 40963 Summary: Upward, lonely robot Demo crashes with Too many buffers queued Product: Wine Version: 1.9.14 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: x3daudio Assignee: wine-bugs(a)winehq.org Reporter: leslie_alistair(a)hotmail.com Distribution: --- Created attachment 55110 --> https://bugs.winehq.org/attachment.cgi?id=55110 Log of +xaudio2 Running Upward, lonely robot Demo, crash after it detects "Too many buffers queued". Log attached. -- 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=40963 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Upward, lonely robot Demo |Upwards, lonely robot Demo |crashes with Too many |crashes with Too many |buffers queued |buffers queued -- 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=40963 --- Comment #1 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Created attachment 55111 --> https://bugs.winehq.org/attachment.cgi?id=55111 A possible fix The issue is caused by nbufs being decreased without check if it's already 0. With this applied the game starts (assuming it doesn't hit a texture bug), and is quite playable. -- 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=40963 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |aeikum(a)codeweavers.com --- Comment #2 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Adding Andrew for comment before upstreaming. -- 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=40963 --- Comment #3 from Andrew Eikum <aeikum(a)codeweavers.com> --- (In reply to Alistair Leslie-Hughes from comment #1)
Created attachment 55111 [details] A possible fix
The issue is caused by nbufs being decreased without check if it's already 0.
With this applied the game starts (assuming it doesn't hit a texture bug), and is quite playable.
This seems like a workaround instead of a proper fix. I think a better solution would be to clear the OpenAL source object's processed buffers during Stop, calling callbacks as needed, then drop any remaining buffers in the source. This should prevent nbufs from being decremented after the flush call, since there should be no more buffers remaining from before the flush. -- 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=40963 --- Comment #4 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- (In reply to Andrew Eikum from comment #3)
I think a better solution would be to clear the OpenAL source object's processed buffers during Stop, calling callbacks as needed, then drop any remaining buffers in the source. This should prevent nbufs from being decremented after the flush call, since there should be no more buffers remaining from before the flush.
Did you want to write it? Happy to test.. -- 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=40963 --- Comment #5 from Andrew Eikum <aeikum(a)codeweavers.com> --- (In reply to Alistair Leslie-Hughes from comment #4)
(In reply to Andrew Eikum from comment #3)
I think a better solution would be to clear the OpenAL source object's processed buffers during Stop, calling callbacks as needed, then drop any remaining buffers in the source. This should prevent nbufs from being decremented after the flush call, since there should be no more buffers remaining from before the flush.
Did you want to write it? Happy to test..
I will when I find time, but I won't be sad if you beat me to it :) -- 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=40963 --- Comment #6 from Andrew Eikum <aeikum(a)codeweavers.com> --- Created attachment 55163 --> https://bugs.winehq.org/attachment.cgi?id=55163 xaudio2: Ignore queued AL buffers after Stop I'm not thrilled with this patch, but I think it will fix it. I wasn't able to find a way to remove buffers from the alSource before they're played. So instead we just ignore them as they're completed playing by OpenAL. -- 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=40963 --- Comment #7 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- (In reply to Andrew Eikum from comment #6)
Created attachment 55163 [details] xaudio2: Ignore queued AL buffers after Stop
I'm not thrilled with this patch, but I think it will fix it.
I wasn't able to find a way to remove buffers from the alSource before they're played. So instead we just ignore them as they're completed playing by OpenAL.
Thanks, confirming that it also fixes the crash. -- 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=40963 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #55111|0 |1 is obsolete| | -- 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=40963 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/xaudio2_7-Aban | |don_Albufs Status|NEW |STAGED CC| |dmitry(a)baikal.ru, | |erich.e.hoover(a)wine-staging | |.com, michael(a)fds-team.de, | |sebastian(a)fds-team.de -- 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=40963 --- Comment #8 from Sebastian Lackner <sebastian(a)fds-team.de> --- (In reply to Andrew Eikum from comment #6)
Created attachment 55163 [details] xaudio2: Ignore queued AL buffers after Stop
I'm not thrilled with this patch, but I think it will fix it.
I wasn't able to find a way to remove buffers from the alSource before they're played. So instead we just ignore them as they're completed playing by OpenAL.
Based on Alistairs request I've added it to Wine Staging anyway. Please note that the patch attached here leads to compiler warnings (unused variables) and contains mistake in the handling of abandoned_albufs.
if(processed > src->abandoned_albufs){ processed -= src->abandoned_albufs; i = src->abandoned_albufs;
Setting i here has no effect.
src->abandoned_albufs = 0;
src->first_al_buf += processed; src->first_al_buf %= XAUDIO2_MAX_QUEUED_BUFFERS; src->al_bufs_used -= processed;
for(i = 0; i < processed; ++i){
This will iterate over the wrong range of buffers. Those issues are fixed in the patch included in Wine Staging. -- 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=40963 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |focht(a)gmx.net --- Comment #9 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, since this is the only ticket that references this staged patchset: https://github.com/wine-compholio/wine-staging/blob/master/patches/xaudio2_7... This patch breaks World of Warships 0.5.16.x and earlier from Wargaming - it crashes shortly after start. Since Wine-Staging is the only way to get decent graphics performance out of the game (CSMT), I've had the patch on my ignore list for months and forgot to report it. Actually I was wondering why no one else reported it the whole time. --- snip --- $ pwd /home/focht/wine-games/wineprefix64-wargaming/drive_c/Games/World_of_Warships $ wine ./WorldOfWarships.exe ... Unhandled exception: page fault on read access to 0x00000054 in 32-bit code (0x0138e860). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:0138e860 ESP:1648e8dc EBP:1648e918 EFLAGS:00210297( R- -- I S -A-P-C) EAX:00000004 EBX:f74d2000 ECX:00000054 EDX:12ba4d34 ESI:14e80cb4 EDI:1648fb40 Backtrace: =>0 0x0138e860 in worldofwarships (+0xf8e860) (0x1648e918) 1 0xf3879396 do_engine_tick+0x232(This=0x211b80) [/home/focht/projects/wine/wine.repo/staging-build-x86/dlls/xaudio2_7/../../include/xaudio2.h:5965] in xaudio2_7 (0x1648e9c8) 2 0xf387966b engine_threadproc+0x94(arg=<couldn't compute location>) [/home/focht/projects/wine/wine.repo/staging-src/dlls/xaudio2_7/xaudio_dll.c:2454] in xaudio2_7 (0x1648e9f8) 3 0x7bc972d4 call_thread_func_wrapper+0xb() in ntdll (0x1648ea28) 4 0x7bc9730f call_thread_func+0x30(entry=0xf38795d6, arg=0x211b80, frame=0x1648eb28) [/home/focht/projects/wine/wine.repo/staging-src/dlls/ntdll/signal_i386.c:2815] in ntdll (0x1648eb08) ... 0x0138e860: movl 0x0(%ecx),%eax Modules: Module Address Debug info Name (204 modules) PE 340000- 38c000 Deferred ortp PE 390000- 3c4000 Deferred ilu_x86r PE 3d0000- 3de000 Deferred gettext_x86r PE 400000- 277c000 Export worldofwarships PE 2780000- 2c7c000 Deferred vivoxsdk PE 2c80000- 2ed3000 Deferred resil_x86r PE 10000000-101ff000 Deferred d3dx9_43 ELF 7a800000-7a942000 Deferred opengl32<elf> \-PE 7a840000-7a942000 \ opengl32 ELF 7b400000-7b7ec000 Deferred kernel32<elf> \-PE 7b420000-7b7ec000 \ kernel32 ELF 7bc00000-7bd11000 Dwarf ntdll<elf> \-PE 7bc30000-7bd11000 \ ntdll ELF 7c000000-7c004000 Deferred <wine-loader> ... Threads: process tid prio (all id:s are in hex) ... 00000091 WargamingGameUpdater.exe 00000095 0 00000092 0 000000b0 (D) C:\Games\World_of_Warships\worldofwarships.exe 000000c7 1 000000c6 0 000000c5 15 000000c4 0 <== 000000c3 0 000000c2 0 000000c1 1 000000c0 0 000000bf 0 000000be 0 000000bd 0 000000bc 0 000000bb 0 000000ba 0 000000b9 0 000000b8 0 000000b7 0 000000b6 0 000000b1 0 ... System information: Wine build: wine-2.0-rc3-900-g9b4c5ab (Staging) Platform: i386 (WOW64) Version: Windows XP Host system: Linux Host version: 4.4.14-200.fc22.x86_64 --- snip --- Better trace: --- snip --- $ WINEDEBUG=+tid,+seh,+relay,+xaudio2 wine ./WorldOfWarships.exe >>log.txt 2>&1 ... 0123:Call KERNEL32.LoadLibraryExW(0032e45e L"C:\\windows\\system32\\xaudio2_7.dll",00000000,00000008) ret=014a19d6 0123:Call PE DLL (proc=0xf3c25695,module=0xf3c10000 L"xaudio2_7.dll",reason=PROCESS_ATTACH,res=(nil)) 0123:trace:xaudio2:DllMain (0xf3c10000, 1, (nil)) ... 0123:Ret PE DLL (proc=0xf3c25695,module=0xf3c10000 L"xaudio2_7.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 0123:Ret KERNEL32.LoadLibraryExW() retval=f3c10000 ret=014a19d6 ... 0123:trace:xaudio2:XAudio2CF_CreateInstance (0xfc87548)->((nil),{8bcf1f58-9fe7-4583-8ac6-e2adc465c8bb},0x32e7dc) ... 0123:trace:xaudio2:IXAudio2Impl_QueryInterface (0xfc87560)->({8bcf1f58-9fe7-4583-8ac6-e2adc465c8bb}, 0x32e7dc) 0123:trace:xaudio2:IXAudio2Impl_AddRef (0xfc87560)->(): Refcount now 1 ... 0123:trace:xaudio2:IXAudio2Impl_StartEngine (0xfc87560)->() 0123:Call KERNEL32.CreateThread(00000000,00000000,f3c255d6,0fc87560,00000000,00000000) ret=f3c239d2 0123:Ret KERNEL32.CreateThread() retval=000001a8 ret=f3c239d2 0123:trace:xaudio2:XAudio2CF_CreateInstance Created XAudio version 27: 0xfc87560 0123:trace:xaudio2:XAudio2CF_Release (0xfc87548)->(): Refcount now 0 ... 0123:Ret ole32.CoCreateInstance() retval=00000000 ret=013fcc69 0123:trace:xaudio2:XA27_Initialize (0xfc87560)->(0x0, 0xffffffff) ... 0133:Starting thread proc 0xf3c255d6 (arg=0xfc87560) ... 0123:trace:xaudio2:XA27_CreateMasteringVoice (0xfc87560)->(0x14e30cc4, 0, 48000, 0x0, 0, (nil)) 0123:trace:xaudio2:IXAudio2Impl_CreateMasteringVoice (0xfc87560)->(0x14e30cc4, 0, 48000, 0x0, L"{0.0.0.00000000}.{FD47D9CC-4218-4135-9CE2-0C195C87405B}", (nil), 0x6) ... 0123:trace:xaudio2:IXAudio2Impl_RegisterForCallbacks (0xfc87560)->(0x14e30cb0) 0123:trace:xaudio2:XA27_GetDeviceDetails 0xfc87560, 0, 0x32e940 ... 0133:trace:xaudio2:do_engine_tick frames available: 1440 ... 0123:trace:xaudio2:IXAudio2Impl_CreateSourceVoice (0xfc87560)->(0x14e30cc8, 0x32ed6c, 0x0, 1.000000, 0x14e30cb4, (nil), (nil)) 0123:trace:xaudio2:dump_fmt wFormatTag: 0xfffe (WAVE_FORMAT_EXTENSIBLE) 0123:trace:xaudio2:dump_fmt nChannels: 2 0123:trace:xaudio2:dump_fmt nSamplesPerSec: 48000 0123:trace:xaudio2:dump_fmt nAvgBytesPerSec: 384000 0123:trace:xaudio2:dump_fmt nBlockAlign: 8 0123:trace:xaudio2:dump_fmt wBitsPerSample: 32 0123:trace:xaudio2:dump_fmt cbSize: 22 0123:trace:xaudio2:dump_fmt dwChannelMask: 00000003 0123:trace:xaudio2:dump_fmt Samples: 0020 0123:trace:xaudio2:dump_fmt SubFormat: {00000003-0000-0010-8000-00aa00389b71} ... 0133:Ret KERNEL32.WaitForSingleObject() retval=00000000 ret=f3c255ff ... 0123:trace:xaudio2:XA2SRC_SetOutputVoices 0xfc8c9d8, (nil) 0123:trace:xaudio2:XA2SRC_SetOutputVoices Outputting to: 0x0, 0xfc87564 ... 0133:trace:xaudio2:do_engine_tick frames available: 1440 ... 0123:trace:xaudio2:IXAudio2Impl_CreateSourceVoice Created source voice: 0xfc8c9d8 0133:trace:xaudio2:do_engine_tick Calling OnVoiceProcessingPassStart with BytesRequired: 19200 0123:trace:xaudio2:XA2SRC_SetVolume 0xfc8c9d8, 1.000000, 0x0 0133:trace:xaudio2:XA2SRC_GetState 0xfc8c9d8, 0x1643e908, 0x0 0133:trace:xaudio2:XA2SRC_GetState returning 0, queued: 0 0123:Call msvcr110.memcpy(0032eda0,0032ede0,0000000c) ret=0132da59 0123:Ret msvcr110.memcpy() retval=0032eda0 ret=0132da59 0133:trace:seh:raise_exception code=c0000005 flags=0 addr=0x138e860 ip=0138e860 tid=0133 0133:trace:seh:raise_exception info[0]=00000000 0133:trace:seh:raise_exception info[1]=00000054 0133:trace:seh:raise_exception eax=00000004 ebx=f7542000 ecx=00000054 edx=1643ef4c esi=14e30cb4 edi=1643fb40 0133:trace:seh:raise_exception ebp=1643e918 esp=1643e8dc cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00210297 ... --- snip --- Slowing down by adding more trace or debugging avoids the crash sometimes but most of the time it crashes immediately. Reverting the patch or skipping it during build ('-W xaudio2_7-Abandon_Albufs') avoids the crash and everything is fine. Regards -- 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=40963 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/xaudio2_7-Aban | |don_Albufs | Status|STAGED |NEW --- Comment #10 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Removing staging reference as it doesn't fix the issue at hand. The original patch by Andrew, even though has compile warnings corrects the issue. The staging patch was changed thus still suffers "Too many buffers queued", since it never updates nbufs which is the cause of the issue. -- 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=40963 Andrew Eikum <aeikum(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #55163|0 |1 is obsolete| | --- Comment #11 from Andrew Eikum <aeikum(a)codeweavers.com> --- Created attachment 59811 --> https://bugs.winehq.org/attachment.cgi?id=59811 xaudio2: Ignore buffers returned from OpenAL after Stop Here's an improved version of the patch that addresses what Sebastian found. Can you confirm it still fixes the issue, Alistair? -- 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=40963 --- Comment #12 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- (In reply to Andrew Eikum from comment #11)
Created attachment 59811 [details] xaudio2: Ignore buffers returned from OpenAL after Stop
Here's an improved version of the patch that addresses what Sebastian found. Can you confirm it still fixes the issue, Alistair?
Yes, the patch fixes the issue. -- 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=40963 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |e2c73fc394bace00c4463b6fcb6 | |dfe9dc64084bc Resolution|--- |FIXED --- Comment #13 from Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> --- Fixed by http://source.winehq.org/git/wine.git/?a=commit;h=e2c73fc394bace00c4463b6fcb... -- 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=40963 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #14 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 3.0-rc1. -- 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=40963 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |2.0.x -- 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=40963 Michael Stefaniuc <mstefani(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.0.x |--- --- Comment #15 from Michael Stefaniuc <mstefani(a)winehq.org> --- Removing the 2.0.x milestone from bugs included in 2.0.5. -- 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