https://bugs.winehq.org/show_bug.cgi?id=56789
Bug ID: 56789 Summary: Wine applications close when computer suspends Product: Wine Version: 9.10 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: jubilantjerry@gmail.com Distribution: ---
Created attachment 76595 --> https://bugs.winehq.org/attachment.cgi?id=76595 Logs for various crashes
All wine applications I've tested seem to crash when I suspend my computer, this includes winecfg, regedit, explorer, taskmgr, WeChat, DingTalk, and Battle.NET.
For the built-in applications above, even clicking on an icon on the top taskbar of the computer, such as the power menu, will cause the application to crash. Locking my computer, opening the start menu, or right clicking on any application's title bar, also causes a crash. I'm scared that even looking at the application funny will cause a crash.
I've attached some application logs during various crash scenarios. I am suspecting the lines with "X Error of failed request:". If the more easily crashing applications, the error will be of type "BadWindow". For the more resilient applications, the error will be of type "XI_BadDevice".
System is running Ubuntu 20.04 LTS. Kernel version is 5.15.0-107-generic Hardware is Dell Inspiron 7577, which has an Intel(R) Core(TM) i5-7300HQ CPU and a Nvidia GTX 1060 Max-Q GPU.
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #1 from jubilantjerry@gmail.com --- I find that any of my wine applications will always crash if I try to open a second application, even the "resilient" ones. So only one application can be open at any point in time, this is very disruptive to my usage.
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #2 from jubilantjerry@gmail.com --- Forgot to mention that when opening a second application, the error on the logs of the crashed application is also of type "X Error of failed request: BadWindow".
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #3 from jubilantjerry@gmail.com --- Starting from a fresh wineserver, by using wineserver -k, I find that the BadWindow crashes don't happen. But once I suspend the computer, and get the XI_BadDevice crashes, all new wine applications opened will be susceptible to BadWindow crashes until I kill the wineserver again.
https://bugs.winehq.org/show_bug.cgi?id=56789
jubilantjerry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Wine applications close |Wine applications crash |when computer suspends |when computer suspends
https://bugs.winehq.org/show_bug.cgi?id=56789
jubilantjerry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |xinput Summary|Wine applications crash |XI_BadDevice crash when |when computer suspends |computer suspends
https://bugs.winehq.org/show_bug.cgi?id=56789
jubilantjerry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|XI_BadDevice crash when |ALL APPLICATIONS: |computer suspends |XI_BadDevice crash when | |computer suspends
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #4 from jubilantjerry@gmail.com --- I've had to downgrade Wine to version 9.3 to get a working setup again. All versions between 9.4 to 9.11 did not work. For now, I'm forced to hold the version to avoid disrupting my work as I wait for the bug report to be noticed at some point in the future.
The updates for Wine 9.4 were: Bundled vkd3d upgraded to version 1.11. Initial OpenGL support in the Wayland driver. Support for elevating process privileges. More HID pointer improvements. Various bug fixes.
The problem with XI_BadDevice should be related to one of these, I'm guessing it could be the OpenGL support.
https://bugs.winehq.org/show_bug.cgi?id=56789
jubilantjerry@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|9.10 |9.11
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl --- ...how do you get from xinput error to an opengl problem ?
Just asking.
I mean, sure, wine has some issues even with dpms blankouts on some monitors, but your problem - with the little info provided - seems like a hardware quirk on your side.
What exactly does 'suspend' mean in your context ?
Also, comment 2 suggests some major miscofiguration (and seemingly on your side not wine)...
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #6 from jubilantjerry@gmail.com --- @Rafał Mużyło
I apologize, I didn't have any good evidence connecting XInput to OpenGL. It was the only pair of features that had results when I searched them together on Google, so my assumption was that they were related.
The errors from comment 2 no longer happen on version 9.11. Originally, they only happened after applications have already crashed due to the suspend event (with error XI_BadDevice). Probably, the Wine server was already in an unstable state after having some applications crashing, causing more crashes that are victims of something else. I agree we can ignore the BadWindow family of problems.
However, the fact remains that I observe all applications crashing on Wine versions 9.4 and above, after the computer suspends. This applies even for built-in applications like winecfg and regedit.
Suspend refers to sleep action caused by the the "pm-suspend" command, which is also the same event that happens when the laptop's lid is closed, when the "Suspend" option from the power menu is chosen, or when the laptop is left idle for a long time. This causes suspend-to-RAM based on what I see in /sys/power/mem_sleep.
I'm not sure if this is related to DPMS. If I understand correctly, there is the suspicion that the bug occurs when the monitor is turned off. However, if I use any of the commands "xset dpms force [off|standby|suspend]", Wine applications do not crash. Only a suspend-to-RAM causes the crash.
I'm not familiar enough with Wine to know what other logs or information to provide, could you suggest additional information beyond the version number, machine details, and Wine logs just prior to the crash event? Thanks.
I use a Dell Inspiron 7577 laptop and did not modify the hardware. Is there information in the logs that point to a hardware problem?
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #7 from jubilantjerry@gmail.com --- Thank you for the response though!
I was a bit distressed thinking that the bug may stay forever, since even though I've downgraded to Wine 9.3, it's not perfect and has its own minor issues. Applications crashing after suspending happens to be a deal-breaker for me, but if this issue is fixed, I can continue to receive the ongoing improvements in stability that the community works hard to create.
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #8 from Rafał Mużyło galtgendo@o2.pl --- Actually, I'm not all that familiar with wine as a whole, just have a history of making guesses, that in non-insignificant part get close to the actual problem.
Now, if you still want my initial guess in this case, commit 800b5e44fc3106930b424ffa852699e499da1993 and the short series starting with c179b269abd8cf8b9bcb1dcb4bd38c697b690097 seem like a good place to start - something seemingly simple (and on most desktops likely is so), but just potentially racy on laptops.
Given that dpms isn't a problem, but card shutdown is, seems like a good point to start digging.
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #9 from jubilantjerry@gmail.com --- So I've tried to build Wine from source to see if the issues are related to these commits, but weirdly I can't seem to reproduce the problem at all with Wine built from source.
I've used the commit corresponding to release 9.13 (e8f936c745b24f794b36a0af794086e0f57c8551). After making a WoW64 build of Wine and then a 32-bit build, I am able to run regedit from the Wine built from source, and it doesn't crash after my laptop suspends.
But version 9.13 installed from my package manager still crashes.
Here are the logs of both, starting from a blank WINEPREFIX:
Wine 9.13 from source: $ WINEPREFIX=/home/jubilantjerry/Downloads/wine-source/wineprefix32 wine32-build/wine regedit wine: created the configuration directory '/home/jubilantjerry/Downloads/wine-source/wineprefix32' 002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 004c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 0054:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 0054:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002 0054:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002 0054:err:ole:apartment_get_local_server_stream Failed: 0x80004002 0054:err:ole:start_rpcss Failed to open RpcSs service 004c:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002 004c:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002 004c:err:ole:apartment_get_local_server_stream Failed: 0x80004002 wine: configuration in L"/home/jubilantjerry/Downloads/wine-source/wineprefix32" has been updated. 0114:fixme:wineusb:query_id Unhandled ID query type 0x5. 0114:fixme:wineusb:query_id Unhandled ID query type 0x5. 0114:fixme:wineusb:query_id Unhandled ID query type 0x5. 0160:fixme:console:default_ctrl_handler Terminating process 14c on event 0
Wine 9.13 from package manager: $ WINEPREFIX=/home/jubilantjerry/Downloads/wine-source/wineprefixbak wine regedit 002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 002c:fixme:winediag:loader_init wine-staging 9.13 is a testing version containing experimental patches. 002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org. 004c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 0054:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 004c:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002 004c:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002 004c:err:ole:apartment_get_local_server_stream Failed: 0x80004002 0054:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002 0054:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002 0054:err:ole:apartment_get_local_server_stream Failed: 0x80004002 0054:err:ole:start_rpcss Failed to open RpcSs service 0080:err:ntoskrnl:ServiceMain Failed to load L"C:\windows\system32\win32k.sys" 0080:err:ntoskrnl:ServiceMain Failed to load L"C:\windows\system32\drivers\dxgkrnl.sys" 0080:err:ntoskrnl:ServiceMain Failed to load L"C:\windows\system32\drivers\dxgmms1.sys" wine: configuration in L"/home/jubilantjerry/Downloads/wine-source/wineprefixbak" has been updated. 010c:fixme:wineusb:query_id Unhandled ID query type 0x5. 010c:fixme:wineusb:query_id Unhandled ID query type 0x5. 010c:fixme:wineusb:query_id Unhandled ID query type 0x5. 010c:fixme:wineusb:query_id Unhandled ID query type 0x5. X Error of failed request: XI_BadDevice (invalid Device parameter) Major opcode of failed request: 131 (XInputExtension) Minor opcode of failed request: 3 (X_OpenDevice) Device id in failed request: 0x249 Serial number of failed request: 249 Current serial number in output stream: 249 X Error of failed request: XI_BadDevice (invalid Device parameter) Major opcode of failed request: 131 (XInputExtension) Minor opcode of failed request: 3 (X_OpenDevice) Device id in failed request: 0x249 Serial number of failed request: 320 Current serial number in output stream: 320
The only real difference I see is err:ntoskrnl:ServiceMain. Though strangely, the Wine from source doesn't have this warning about 9.13 being a testing version.
I've also attached the logs I get from the configuration process before building Wine from source.
I'm not sure what I can try to continue to narrow down the problem... let me know how I should proceed so that I can reproduce the problem that I observe in the release build, and then narrow the problem to a specific commit.
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #10 from jubilantjerry@gmail.com --- Created attachment 76832 --> https://bugs.winehq.org/attachment.cgi?id=76832 Configure output for 64-bit Wine
The command: ../wine/configure --enable-win64
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #11 from jubilantjerry@gmail.com --- Created attachment 76833 --> https://bugs.winehq.org/attachment.cgi?id=76833 Configure output for 32-bit Wine
The command: PKG_CONFIG_PATH=/usr/lib32 ../wine/configure --with-wine64=../wine64-build
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #12 from jubilantjerry@gmail.com --- I've discovered that Wine can output more verbose logs, so I tried capturing the logs of a minimal crash scenario.
With the default logging verbosity, my scenario produces: ``` $ WINEPREFIX=/home/jubilantjerry/Downloads/wine-source/wineprefixbak wine64 regedit 002c:fixme:winediag:loader_init wine-staging 9.13 is a testing version containing experimental patches. 002c:fixme:winediag:loader_init Please mention your exact version when filing bug reports on winehq.org. 0080:fixme:wineusb:query_id Unhandled ID query type 0x5. 0080:fixme:wineusb:query_id Unhandled ID query type 0x5. 0080:fixme:wineusb:query_id Unhandled ID query type 0x5. 0080:fixme:wineusb:query_id Unhandled ID query type 0x5. X Error of failed request: XI_BadDevice (invalid Device parameter) Major opcode of failed request: 131 (XInputExtension) Minor opcode of failed request: 3 (X_OpenDevice) Device id in failed request: 0x249 Serial number of failed request: 248 Current serial number in output stream: 248 X Error of failed request: XI_BadDevice (invalid Device parameter) Major opcode of failed request: 131 (XInputExtension) Minor opcode of failed request: 3 (X_OpenDevice) Device id in failed request: 0x249 Serial number of failed request: 313 Current serial number in output stream: 313 ```
Nothing in this looks particularly strange to me, prior to the error.
I then tried with WINEDEBUG=+all,trace-all, comparing the release version of Wine 9.13 with my built from source Wine 9.13.
The logs near the crash in the release version look like: ``` 0138:warn:keyboard:X11DRV_InitKeyboard vkey 012C is being used by more than one keycode 0138:warn:keyboard:X11DRV_InitKeyboard vkey 01B4 is being used by more than one keycode 0138:warn:keyboard:X11DRV_InitKeyboard vkey 0003 is being used by more than one keycode 0138:warn:keyboard:X11DRV_InitKeyboard No more vkeys available! 0138:warn:file:NtCreateFile L"\??\C:\windows\uxtheme.dll" not found (c0000034) 0138:warn:file:NtCreateFile L"\??\C:\windows\ole32.dll" not found (c0000034) 0138:warn:file:NtCreateFile L"\??\C:\windows\combase.dll" not found (c0000034) 0138:warn:file:NtCreateFile L"\??\C:\windows\rpcrt4.dll" not found (c0000034) 0138:warn:file:NtCreateFile L"\??\C:\windows\coml2.dll" not found (c0000034) 0138:warn:gdi:handle_entry invalid handle 0x1 0138:warn:gdi:handle_entry invalid handle 0x1 0138:warn:file:NtCreateFile L"\??\C:\windows\msimg32.dll" not found (c0000034) 0138:warn:gdi:handle_entry invalid handle 0x130400a6 X Error of failed request: XI_BadDevice (invalid Device parameter) Major opcode of failed request: 131 (XInputExtension) Minor opcode of failed request: 3 (X_OpenDevice) Device id in failed request: 0x249 Serial number of failed request: 245 Current serial number in output stream: 245 X Error of failed request: XI_BadDevice (invalid Device parameter) Major opcode of failed request: 131 (XInputExtension) Minor opcode of failed request: 3 (X_OpenDevice) Device id in failed request: 0x249 Serial number of failed request: 313 Current serial number in output stream: 313 ```
The built from source version also has the warnings about "msimg32.dll not found" or "invalid handle 0x130400a6". Yet, the built from source version doesn't get the X Error crash. So these warnings also look like red herrings, unfortunately.
Finally, I tried capturing logs at maximum verbosity. The X Error now looks different, here are the logs around the crash: ``` 68408.293:0044:0070:trace:mountmgr:udisks_filter changed "/org/freedesktop/NetworkManager/Devices/3" 68408.309:0044:0070:trace:mountmgr:udisks_filter changed "/org/freedesktop/NetworkManager/Devices/3" 68408.309:0044:0070:trace:mountmgr:udisks_filter changed "/org/freedesktop/NetworkManager" 68408.486:0044:0070:trace:mountmgr:udisks_filter changed "/org/bluez/hci0" 68409.420:0044:0070:trace:mountmgr:udisks_filter changed "/org/freedesktop/login1" 68409.681:0064:0068:err:x11drv:error_handler X protocol error: serial=611, request_code=131 - breaking into debugger plorer.exe: dlls/winex11.drv/x11drv_main.c:296: error_handler: Assertion `0' failed. 68409.681:0064:0068:warn:virtual:virtual_setup_exception exception outside of stack limits addr 0x7f5b47b6a00b stack 0x1000ff1e0 (0x4d0000-0x4d2000-0x6d0000) 68409.681:0064:0068:trace:seh:dispatch_exception code=80000101 (EXCEPTION_WINE_ASSERTION) flags=1 addr=00007F5B47B6A00B 68409.681:0064:0068:trace:seh:dispatch_exception rip=00007f5b47b6a00b rsp=00000001000ff1e0 rbp=00007f5b47cdf588 eflags=00000246 68409.681:0064:0068:trace:seh:dispatch_exception rax=0000000000000000 rbx=00007f5b47b25f40 rcx=00007f5b47b6a00b rdx=0000000000000000 68409.681:0064:0068:trace:seh:dispatch_exception rsi=00000001000ff1e0 rdi=0000000000000002 r8=0000000000000000 r9=00000001000ff1e0 68409.681:0064:0068:trace:seh:dispatch_exception r10=0000000000000008 r11=0000000000000246 r12=00007f5b466e90f8 r13=0000000000000128 68409.681:0064:0068:trace:seh:dispatch_exception r14=00007f5b466eab3d r15=000055555693ea50 mxcsr=00001fa0 68409.681:0064:0068:trace:unwind:dwarf_virtual_unwind function 7f5b47b6a00b base 0x7f5b47b69f40 cie 0x7f5b47ceb590 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip 68409.681:0064:0068:trace:unwind:execute_cfa_instructions 7f5b47b69f40: DW_CFA_def_cfa %rsp, 8 68409.681:0064:0068:trace:unwind:execute_cfa_instructions 7f5b47b69f40: DW_CFA_offset %rip, -8 68409.681:0064:0068:trace:unwind:dwarf_virtual_unwind fde 0x7f5b47ceda70 len 18 personality (nil) lsda (nil) code 7f5b47b69f40-7f5b47b6a049 68409.681:0064:0068:trace:unwind:execute_cfa_instructions 7f5b47b69f40: DW_CFA_advance_loc 11 68409.681:0064:0068:trace:unwind:execute_cfa_instructions 7f5b47b69f4b: DW_CFA_def_cfa_offset 288 68409.681:0064:0068:trace:unwind:execute_cfa_instructions 7f5b47b69f4b: DW_CFA_advance_loc1 221 68409.681:0064:0068:trace:unwind:dwarf_virtual_unwind next function rip=00007f5b47b49859 68409.681:0064:0068:trace:unwind:dwarf_virtual_unwind rax=0000000000000000 rbx=00007f5b47b25f40 rcx=00007f5b47b6a00b rdx=0000000000000000 68409.681:0064:0068:trace:unwind:dwarf_virtual_unwind rsi=00000001000ff1e0 rdi=0000000000000002 rbp=00007f5b47cdf588 rsp=00000001000ff300 68409.681:0064:0068:trace:unwind:dwarf_virtual_unwind r8=0000000000000000 r9=00000001000ff1e0 r10=0000000000000008 r11=0000000000000246 68409.681:0064:0068:trace:unwind:dwarf_virtual_unwind r12=00007f5b466e90f8 r13=0000000000000128 r14=00007f5b466eab3d r15=000055555693ea50 68409.681:0064:0068:err:seh:call_seh_handlers invalid frame 00000001000FF1E0 (00000000004D2000-00000000006D0000) 68409.681:0064:0068:err:seh:NtRaiseException Exception frame is not in stack limits => unable to dispatch exception. 0068: terminate_process( handle=ffffffff, exit_code=1202507248 ) 010c: *killed* exit_code=1202507248 010c: *sent signal* signal=3 0110: *killed* exit_code=1202507248 0114: *killed* exit_code=1202507248 0068: terminate_process() = 0 { self=1 } 68409.691:0148:014c:trace:winstation:get_shared_queue lock 0x1000ffa40, queue_shm 0x1000ffa38 68409.691:0148:014c:trace:winstation:get_shared_queue lock 0x1000ffa40, queue_shm 0x1000ffa38 ```
Weirdly, the serial number is changed to 611 and it doesn't mention a Bad Device, but I think the root cause may be the same. Perhaps these logs can be used to narrow down to a specific line of code in Wine?
I've attached the warn logs from the crashing run, the warn logs from the working run, and the trace logs from the crashing run.
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #13 from jubilantjerry@gmail.com --- Created attachment 76834 --> https://bugs.winehq.org/attachment.cgi?id=76834 Warning logs from release 9.13 (crashed)
Command: WINEDEBUG=+all,trace-all WINEPREFIX=/home/jubilantjerry/Downloads/wine-source/wineprefixbak wine64 regedit
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #14 from jubilantjerry@gmail.com --- Created attachment 76835 --> https://bugs.winehq.org/attachment.cgi?id=76835 Warning logs from built from source 9.13 (didn't crash)
Command: WINEDEBUG=+all,trace-all WINEPREFIX=/home/jubilantjerry/Downloads/wine-source/wineprefix64 wine64-build/wine64 regedit
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #15 from jubilantjerry@gmail.com --- Created attachment 76836 --> https://bugs.winehq.org/attachment.cgi?id=76836 Trace logs from release 9.13 (crashed)
Command: WINEDEBUG=+all WINEPREFIX=/home/jubilantjerry/Downloads/wine-source/wineprefixbak wine64 regedit
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #16 from Dmitry Timoshkov dmitry@baikal.ru --- (In reply to jubilantjerry from comment #9)
The only real difference I see is err:ntoskrnl:ServiceMain. Though strangely, the Wine from source doesn't have this warning about 9.13 being a testing version.
This may indicate that your distribution ships wine-staging instead of winehq, and in that case one of the patches in the staging tree causes XI_BadDevice errors.
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #17 from jubilantjerry@gmail.com --- Thanks for the tip, I didn't know I had to apply patches to reproduce the staging version. I've finally reproduced the bug with Wine 9.13 Staging built from source. Now I have to binary search for the commit that introduced the bug.
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #18 from jubilantjerry@gmail.com --- I've narrowed down the bug to a specific feature. It is indeed something in Wine-staging that causes the problem.
When basing on commit 1719aef8cbc99994ec93848ae6e9e29e5c4beb78 (Release 9.4) in Wine, the bug does not appear when I apply the patches from Wine-staging at commit daf7cb4cb9c8dbdc8850c8189eacd4302e1a76b6.
But if I use the patches from Wine-staging at commit aa8b27c396f926212689d18da91778f5f8821c6d, followed by a cherry-pick of 50bad5b9aff29bae6af6cc84a2e7b9efd30b0999, the bug appears.
Both commits in Wine-staging are related to "user32-rawinput-mouse" and pushed by alesliehughes. I needed to apply both commits in order for Wine to compile. The bug is reproducible using any version of Wine-staging after both commits.
Is the bug considered confirmed at this point? I don't have any knowledge of the codebase so I can't say why this particular commit causes problems or how one can fix it. Let me know if you need me to test any patches on my machine to see if the crash is fixed.
https://bugs.winehq.org/show_bug.cgi?id=56789
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 CC| |leslie_alistair@hotmail.com | |, rbernon@codeweavers.com, | |z.figura12@gmail.com Component|xinput |-unknown Status|UNCONFIRMED |NEW Product|Wine |Wine-staging
--- Comment #19 from Dmitry Timoshkov dmitry@baikal.ru --- Changing product to wine-staging, and adding author of the patches to CC:.
https://bugs.winehq.org/show_bug.cgi?id=56789
talchas@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |talchas@gmail.com
--- Comment #20 from talchas@gmail.com --- Yeah, a simpler way to trigger this is to just unplug your mouse / plug in a new one. The DeviceChanged event->sourceid is 0, not a valid device id, so XOpenDevice in update_device_mapping just dies.
I don't know if this should be event->deviceid in the first place (which is valid) or if it should just be skipped if sourceid is unset, but my guess from the vague text in XI2proto.txt is that sourceid is only set on reason == SlaveSwich.
As a somewhat separate issue, update_device_mapping tries to be defensive and catch XOpenDevice failures, but forgets that the Xlib API around errors is awful, and thus doesn't actually catch the error and the program just dies. (I'm not 100% sure if it would be possible to set up error_handler/ignore_error to work or not)
A typical event printed in gdb:
{type = 35, serial = 347, send_event = 0, display = 0x565c9590, extension = 131, evtype = 1, time = 1663560125, deviceid = 2, sourceid = 0, reason = 2, num_classes = 5, classes = 0x565d54c0}
https://bugs.winehq.org/show_bug.cgi?id=56789
--- Comment #21 from talchas@gmail.com --- Actually, you can't even XOpenDevice the core pointer for whatever reason, and it looks like x11drv_xinput2_init is only trying to listen to the core devices in the first place, so I think the most it could do is just clear device_mapping (otoh, it's not like button_count is being used at the moment, so it's extra harmless to do all that).
-
WineHQ Bugzilla