[Bug 48946] New: Uplay crash when launching Watchdogs with esync patch applied
https://bugs.winehq.org/show_bug.cgi?id=48946 Bug ID: 48946 Summary: Uplay crash when launching Watchdogs with esync patch applied Product: Wine-staging Version: 5.6 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: guillaume.zin(a)gmail.com CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com Distribution: --- Created attachment 66920 --> https://bugs.winehq.org/attachment.cgi?id=66920 Patch to esync, adds sanity checks in queue_rawinput_message Hello, I first decribed the problem here: https://github.com/lutris/wine/issues/25 With wine version 5.5 and 5.6 patched with esync, wineserver crashes most of the time (sometimes it doesn't) when Uplay is about to launch Watchdogs (when the dialog box appears to explain that disabling uplay overlay is not such a good idea, or when telling it is starting the game). It doesn't happen with vanilla wine. Wine 5.6 + esync patch + -ggdb option during compilation: Program received signal SIGSEGV, Segmentation fault. 0x000055baca61f208 in queue_rawinput_message (process=0x55bacb873200, user=0x7fff020150c0) at ../../wine/server/queue.c:1808 1808 ../../wine/server/queue.c: Aucun fichier ou dossier de ce type. (gdb) backtrace #0 0x000055baca61f208 in queue_rawinput_message (process=0x55bacb873200, user=0x7fff020150c0) at ../../wine/server/queue.c:1808 #1 0x000055baca619558 in enum_processes (cb=cb(a)entry=0x55baca61f140 <queue_rawinput_message>, user=user(a)entry=0x7fff020150c0) at ../../wine/server/process.c:1080 #2 0x000055baca620f21 in queue_mouse_message (req_flags=<optimized out>, sender=0x55bacbae5930, origin=1, input=0x55bacb588eb0, win=0, desktop=0x55bacb588110) at ../../wine/server/queue.c:1901 #3 req_send_hardware_message (req=0x55bacb588ea0, reply=0x7fff02015160) at ../../wine/server/queue.c:2608 #4 0x000055baca62a8d3 in call_req_handler (thread=thread(a)entry=0x55bacb588d50) at ../../wine/server/request.c:311 #5 0x000055baca62b902 in read_request (thread=thread(a)entry=0x55bacb588d50) at ../../wine/server/request.c:345 #6 0x000055baca6314b0 in thread_poll_event (fd=<optimized out>, event=1) at ../../wine/server/thread.c:319 #7 0x000055baca60a106 in fd_poll_event (event=<optimized out>, fd=<optimized out>) at ../../wine/server/fd.c:486 #8 main_loop_epoll () at ../../wine/server/fd.c:581 #9 0x000055baca60a37e in main_loop () at ../../wine/server/fd.c:947 #10 0x000055baca5f9989 in main (argc=1, argv=0x7fff02015948) at ../../wine/server/main.c:154 The attached patch, applied after esync patch, fixes the problem. Guillaume -- 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=48946 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com -- 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=48946 --- Comment #1 from Rémi Bernon <rbernon(a)codeweavers.com> --- The patch should probably go to the user32-rawinput-mouse staging series, but it may then require a rebase of the user32-rawinput-nolegacy series. There's going to be conflicts because two consecutive lines are touched although the merge is actually trivial. -- 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=48946 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Fixed by SHA1| |8d4d0a840e6ce434483edd81acb | |3be90fd734e44 Resolution|--- |FIXED --- Comment #2 from Zebediah Figura <z.figura12(a)gmail.com> --- This is fixed by <https://github.com/wine-staging/wine-staging/commit/8d4d0a840e6ce434483edd81acb3be90fd734e44>. What does esync have to do with anything, though? -- 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=48946 --- Comment #3 from Rémi Bernon <rbernon(a)codeweavers.com> --- Thanks! I don't know why esync is involved, but maybe it creates the conditions for the crash to happen. It crashed when there's no foreground_input thread on the desktop, I'm not sure if or how it's supposed to happen. -- 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=48946 --- Comment #4 from Guillaume <guillaume.zin(a)gmail.com> --- esync is involved because I had the bug when applying the eventfd_synchronization patch. But looking at https://github.com/wine-staging/wine-staging/blob/master/patches/patchinstal..., I understand now that this patch applies a patch set including the user32_rawinput_mouse patch. -- 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=48946 GloriousEggroll(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |GloriousEggroll(a)gmail.com --- Comment #5 from GloriousEggroll(a)gmail.com --- This change seems to cause the window to close if you don't click into it so that it realizes it has focus. Happened when testing on both Watch Dogs 2 and Resident Evil 4. Removing this check: + if (!device->target && !desktop->foreground_input) + goto done; Seems to work ok in both games from my end. -- 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=48946 --- Comment #6 from GloriousEggroll(a)gmail.com --- What I mean is - if you launch the game, then click something else or otherwise cause the mouse to focus elsewhere, the game will try to open, then immediately close. If you click the black screen it produces shortly before initializing, it will sense that focus is active and continue to load as intended. Removing the check mentioned above allows the game to load regardless. -- 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=48946 --- Comment #7 from Guillaume <guillaume.zin(a)gmail.com> --- I don't understand, it makes no sense: it means that sometimes, you enter the function with device->target and desktop->foreground_input = 0. It should crash on "device->target ? device->target : desktop->foreground_input->active" without the sanity check, isn'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=48946 --- Comment #8 from Guillaume <guillaume.zin(a)gmail.com> --- Created attachment 66953 --> https://bugs.winehq.org/attachment.cgi?id=66953 user32_rawinput_mouse cleaner patches These patches makes the code more readily understandable I think, but I'm not sure it will fix GloriousEggroll troubles with Watch Dogs 2 and Resident Evil 4. One patch is to apply on vanilla Wine 5.6, the other on current staging code. -- 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=48946 --- Comment #9 from Rémi Bernon <rbernon(a)codeweavers.com> --- I don't think they are right though. If the registered rawinput device has no target window, the messages should be sent to the foreground window. With your changes, "thread = get_window_thread( device->target )" will be NULL in this case and the message will be discarded. Regarding GloriousEggroll issue, I'm not sure to see how that's ever related to rawinput. If the window is not foreground it isn't supposed to receive any rawinput message, unless RIDEV_INPUTSINK is also implemented, which is done in a different patch series. I will investigate a bit but I'm on something else right now, so it may take a while. -- 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=48946 --- Comment #10 from Guillaume <guillaume.zin(a)gmail.com> --- In my understanding, get_window_thread is used on device->target then on desktop->foreground_input->active just to compare with message process and check that the message is the for the foreground thread, otherwise it is discarded. Thread object is not used afterwards. But the code is odd in the current state, and I'm clearly not an expert. -- 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=48946 --- Comment #11 from Rémi Bernon <rbernon(a)codeweavers.com> --- The code iterates the process list on every rawinput message to see which one is interested. Then, every process can register for rawinput message and may specify a target window, or let the system send the message to the foreground window if it belongs to the given process. The first implements that by getting the target thread for the device (either the owner of the target window, or the foreground thread), then it compares with the process that is currently checked, and if the thread is from another process bails out - this other process will get its own iteration step and receive the message if it is interested. Then, the second if implements a different check where, if the target thread is not from the foreground process (the process to which belongs the foreground window), then we should only sent the messages if a specific flag is used, which is first unimplemented -not supporting RIDEV_INPUTSINK flag / WM_INPUTSINK messages, and then later implemented in a different patch series. -- 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=48946 --- Comment #12 from Guillaume <guillaume.zin(a)gmail.com> --- I see, so forget the user32_rawinput_mouse cleaner patches, it might break work in progress. Thank you for the explanations. -- 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=48946 --- Comment #13 from GloriousEggroll(a)gmail.com --- I did a double check on this - the fix is fine and correct. I had another upstream pending patch applied that's doing some really funky stuff with clipping that doesnt seem to work properly: (https://bugs.winehq.org/show_bug.cgi?id=48772) for reference -- 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=48946 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #14 from Zebediah Figura <z.figura12(a)gmail.com> --- Closing bugs fixed in wine-staging 5.7. -- 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)
-
WineHQ Bugzilla