[Bug 59393] New: SERVICE_INTERACTIVE_PROCESS services don't work properly
http://bugs.winehq.org/show_bug.cgi?id=59393 Bug ID: 59393 Summary: SERVICE_INTERACTIVE_PROCESS services don't work properly Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs@list.winehq.org Reporter: lina@lina.yt Distribution: --- service_run_main_thread() calls ProcessWineMakeProcessSystem, which makes the thread a system process. A system process is not allowed to keep a desktop alive, per the logic in server/winstation.c. When such a process tries to create a window, such as by calling MessageBoxA(), it ends up in winstation_init(), which creates a desktop and assigns it to the current process. This launches explorer.exe. However, this desktop isn't actually ever owned by the service, because it is a system process. This is an unstable state. If any other process/thread is assigned/released a desktop at this point, server/winstation.c will kill explorer.exe by sending it WM_CLOSE. This a race. Sequence of events: - Service Process starts - It becomes a system process after running the main service dispatcher - Service calls MessageBoxA() - X11DRV_create_win_data -> init_clip_window() grabs the clip_window ID from explorer.exe - Some other process/thread owns a desktop and becomes system, exits, or whatever. - The close_timeout triggers, and explorer.exe is told to exit - The clip_window is destroyed - Any clip_window operations (such as ungrab_clipping_window() via X11DRV_ClipCursor) trigger a BadWindow X11 error and kill the service This is happening on Proton partially due to some Proton changes (that cause the sequence of events above to actually happen almost 100% reliably), but I believe the fundamental problem exists in vanilla Wine. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59393 --- Comment #1 from Hoshino Lina <lina@lina.yt> --- I should mention that what I'm trying to do here is have a SERVICE_INTERACTIVE_PROCESS service that nonetheless behaves like a system process in the sense that it does not keep wineserver alive just by existing. So it would not be sufficient to make SERVICE_INTERACTIVE_PROCESS services non-system since that would defeat the purpose. I'm guessing that without the winstation exclusion logic, explorer.exe would also keep the session alive. So perhaps explorer.exe itself should be marked system, and then the winstation logic not applied to SERVICE_INTERACTIVE_PROCESS services (despite them otherwise still being a System process)? That way they could keep explorer.exe alive, and everything still would be killed when all non-service processes exit. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=59393 --- Comment #2 from Hoshino Lina <lina@lina.yt> --- Another option would be to just remove the winstation exclusion logic only for such service processes. I think I can probably make the service only attach to a desktop when it needs it (right now, only to show error messages) and detach itself when it is just running in the background (the service does not need to show any windows during normal operation, the interactive flag is mostly there to be able to open DirectX). That should be enough to make sure the service doesn't keep explorer.exe up when not needed, and then that would allow the whole session to be torn down properly on demand. -- 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