[Bug 54283] New: dinput:force_feedback - test_windows_gaming_input() sometimes crashes on Windows and Wine
https://bugs.winehq.org/show_bug.cgi?id=54283
Bug ID: 54283 Summary: dinput:force_feedback - test_windows_gaming_input() sometimes crashes on Windows and Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: dinput Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com
dinput:force_feedback - test_windows_gaming_input() sometimes crashes on Windows :
force_feedback.c:6324: Test failed: TryResetAsync returned 0x86854001 force_feedback.c:6324: this is the last test seen before the exception 06a0:force_feedback: unhandled exception c0000005 at 000000000041B540
And Wine:
force_feedback.c:6479: Test marked todo: Stop returned 0x8000ffff force_feedback.c:4864: iface 006C886C, async 019D8AF8, status 1 force_feedback.c:4779: iface 006C886C, async 019D8AF8, status 1 force_feedback.c:4864: iface 006C886C, async 019D8AF8, status 1 force_feedback.c:4779: iface 006C886C, async 019C09E0, status 1 force_feedback.c:4864: iface 006C886C, async 019C09E0, status 1 force_feedback.c:4779: iface 006C886C, async 019C09E0, status 1 Unhandled exception: page fault on read access to 0x00000008 in 32-bit code (0x6fc81461). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:6fc81461 ESP:0389fdc0 EBP:0389fe08 EFLAGS:00010206( R- -- I - -P- ) EAX:00000000 EBX:0389fde0 ECX:006c886c EDX:00000000 ESI:019d8af8 EDI:019d9b28 Stack dump: 0x0389fdc0: 006c886c 019d8af8 00000001 00000001 0x0389fdd0: 00184f80 00000001 019d9b48 006c886c 0x0389fde0: 00000013 00000000 00000000 7bc5c97f 0x0389fdf0: 00184fc4 00000000 0389fe20 00185024 0x0389fe00: 00184f80 019d9b28 0389feb8 7bc602c6 0x0389fe10: 00000000 00000000 0389fe40 7bc602c6 Backtrace: =>0 0x6fc81461 __x_ABI_CWindows_CGaming_CInput_CCustom_CIWineAsyncOperationCompletedHandler_Release+0xb(This=<internal error>) [Z:\home\winetest\tools\testbot\var\wine-win32\dlls\windows.gaming.input\provider.h:386] in windows.gaming.input (0x0389fe08) 1 0x6fc81461 async_info_callback+0xc1(instance=<couldn't compute location>, iface=<couldn't compute location>, work=<couldn't compute location>) [Z:\home\winetest\tools\testbot\var\wine\dlls\windows.gaming.input\async.c:321] in windows.gaming.input (0x0389fe08) 2 0x7bc602c6 tp_object_execute+0x2b6(object=<register ESI not accessible in this frame>, wait_thread=0) [Z:\home\winetest\tools\testbot\var\wine\dlls\ntdll\threadpool.c:2242] in ntdll (0x0389feb8) 3 0x7bc60770 threadpool_worker_proc+0x110(param=<couldn't compute location>) [Z:\home\winetest\tools\testbot\var\wine\dlls\ntdll\threadpool.c:2356] in ntdll (0x0389ff28) 4 0x7b62a290 in kernel32 (+0x2a290) (0x0389ff48) 5 0x7bc5cfa7 in ntdll (+0x5cfa7) (0x0389ff5c) 6 0x7bc5d7d0 RtlCreateUserThread(entry=7BC60660, arg=00185018) [Z:\home\winetest\tools\testbot\var\wine\dlls\ntdll\thread.c:306] in ntdll (0x0389ffec) 0x6fc81461 async_info_callback+0xc1 [Z:\home\winetest\tools\testbot\var\wine\dlls\windows.gaming.input\async.c:321] in windows.gaming.input: call *0x8(%eax) 321 LeaveCriticalSection( &impl->cs );
See https://test.winehq.org/data/patterns.html#dinput:force_feedback
This failure was first seen on 2023-01-06 and can happen on Windows 10 (e.g. w1064-tsign-64) as well as Wine.
https://bugs.winehq.org/show_bug.cgi?id=54283
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase
https://bugs.winehq.org/show_bug.cgi?id=54283
--- Comment #1 from François Gouget fgouget@codeweavers.com --- In Wine one more often gets an execute exception:
Unhandled exception: page fault on execute access to 0x0202ca53 in 32-bit code (0x0202ca53 ). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:0202ca53 ESP:0389fdbc EBP:0389fe08 EFLAGS:00010206( R- -- I - -P- ) EAX:0146d884 EBX:0389fde0 ECX:006c886c EDX:00000000 ESI:019d2db8 EDI:019e2010 Stack dump: 0x0389fdbc: 6fc81464 006c886c 019d2db8 00000001 0x0389fdcc: 00000001 00177c18 00000001 019e2030 0x0389fddc: 006c886c 0000000b 00000000 00000001 0x0389fdec: 7bc5c97f 00177c5c 00000000 0389fe20 0x0389fdfc: 00167cd4 00177c18 019e2010 0389feb8 0x0389fe0c: 7bc602c6 00000000 00000000 0389fe40 Backtrace: =>0 0x0202ca53 (0x0389fe08) 1 0x7bc602c6 tp_object_execute+0x2b6(object=019D2DB8, wait_thread=0) [Z:\home\winetest\t ools\testbot\var\wine\dlls\ntdll\threadpool.c:2242] in ntdll (0x0389feb8) 2 0x7bc60770 threadpool_worker_proc+0x110(param=<couldn't compute location>) [Z:\home\wi netest\tools\testbot\var\wine\dlls\ntdll\threadpool.c:2356] in ntdll (0x0389ff28) 3 0x7b62a290 in kernel32 (+0x2a290) (0x0389ff48) 4 0x7bc5cfa7 in ntdll (+0x5cfa7) (0x0389ff5c) 5 0x7bc5d7d0 RtlCreateUserThread(entry=7BC60660, arg=00167CC8) [Z:\home\winetest\tools\t estbot\var\wine\dlls\ntdll\thread.c:306] in ntdll (0x0389ffec)
https://bugs.winehq.org/show_bug.cgi?id=54283
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=54283
--- Comment #2 from Rémi Bernon rbernon@codeweavers.com --- I think the two are different issues.
The windows failure I believe started to happen because the reduced verbosity changed some timing, and it looks like the async operation cancellation now happens successfully when it was expected to have no effect, and causes later tests to fail differently.
The Wine issue is more puzzling, I couldn't reproduce it locally yet.
https://bugs.winehq.org/show_bug.cgi?id=54283
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|dinput:force_feedback - |dinput:force_feedback - |test_windows_gaming_input() |test_windows_gaming_input() |sometimes crashes on |sometimes crashes on |Windows and Wine |Windows Regression SHA1| |19fb59eb97c32e3aae7c9faa643 | |804fe8450a5c0 Keywords| |regression
--- Comment #3 from François Gouget fgouget@codeweavers.com --- Ah. I did hit the "reduce verbosity" commit in a couple of bisects but it did not feel right since that patch is so innocuous!
In fact I just hit it once more looking for the Windows crash. So it's an official regression now :-/
commit 19fb59eb97c32e3aae7c9faa643804fe8450a5c0 Author: Rémi Bernon rbernon@codeweavers.com Date: Mon Jan 2 12:07:54 2023 +0100
dinput/tests: Reduce tests verbosity.
The Wine crash is harder to reproduce since it's not (less) systematic and it may have been present for longer. It's not clear. So let's put it aside for now (i.e. I removed "and Wine" from the bug title and maybe it will go in a separate bug).
https://bugs.winehq.org/show_bug.cgi?id=54283
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |3a0de91ecf7c0b2b968c51bf90f | |9c1e5f9904a88 Resolution|--- |FIXED
--- Comment #4 from Rémi Bernon rbernon@codeweavers.com --- The Windows failure should be fixed after 3a0de91ecf7c0b2b968c51bf90f9c1e5f9904a88.
https://bugs.winehq.org/show_bug.cgi?id=54283
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #5 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.0-rc5.
https://bugs.winehq.org/show_bug.cgi?id=54283
--- Comment #6 from Rémi Bernon rbernon@codeweavers.com --- FWIW I think the Wine crash in Windows.Gaming.Input is the same issue as elsewhere with threads still running at process shutdown and crashing from their module being unloaded behind their feet on process shutdown.
https://bugs.winehq.org/show_bug.cgi?id=54283
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- (In reply to Rémi Bernon from comment #6)
FWIW I think the Wine crash in Windows.Gaming.Input is the same issue as elsewhere with threads still running at process shutdown and crashing from their module being unloaded behind their feet on process shutdown.
Modules should not be unloaded at process shutdown, that's a waste of time. If there's any library that does this, it should be fixed.
https://bugs.winehq.org/show_bug.cgi?id=54283
--- Comment #8 from Rémi Bernon rbernon@codeweavers.com --- Hmm, you're right. Because of the symptoms I thought it was something like that, and although modules are detached they aren't unmapped. Nevermind then.
-
WineHQ Bugzilla