Bug 107672

Summary:	Complete freeze if breakpoint is placed in gtk signal handler
Product:	Wayland	Reporter:	Gunter Königsmann <gunter>
Component:	XWayland	Assignee:	Wayland bug list <wayland-bugs>
Status:	RESOLVED MOVED	QA Contact:	Xorg Project Team <xorg-team>
Severity:	normal
Priority:	medium
Version:	1.0.x
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Gunter Königsmann 2018-08-24 06:13:41 UTC

If you place a gdb breakpoint in in a signal handler of a wxGTK or GTK application (for example MathCtrl::OnPaint in wxMaxima) mouse, screen and keyboard completely freeze, if this event handler was triggered by a GUI event. The keyboard is physically working, still, and with a bit of luck one can switch from wayland to a text console and kill gdb from there - which returns the wayland session to a working order.

Don't know if that is a bug or if it is completely unavoidable so I would accept a "WONTFIX".

Comment 1 Gunter Königsmann 2018-08-24 06:15:24 UTC

Original bug report: https://groups.google.com/forum/m/#!topic/wx-users/cgS-6YQ1Yw8

Comment 2 Pekka Paalanen 2018-08-24 07:50:59 UTC

Which Wayland compositor (desktop environment) are you using?

Why is this filed as an Xwayland bug?

The terminal from where you run gdb, is it using Wayland or X11? Is the application being debugged using Wayland or X11?

If it so happens that the app being debugged is using X11, you might be stopping the application while it is holding Xwayland (the X11 server) hostage (a server grab, this is perfectly normal in X11 world). This makes the X server not process any other clients, a terminal app and even the Wayland compositor included. So my best guess is that the app is holding an X server grab, the Wayland compositor is doing something blocking with Xwayland, and this leads to seemingly everything freezing.

Another option is that while the X server is grabbed, all things that use X11 are frozen, but maybe not the Wayland compositor because you say you can sometimes switch to another VT.

If the issue really is the X11 server grab, then I'm afraid that is just how things are intended to work. One might mitigate the issues by replacing blocking X11 calls in the Wayland compositor with async ones, but that can be hard.

Or, it could be something completely different. Nothing yet points to an Xwayland bug, though.

If the application to be debugged was using Wayland, no such freeze should happen, so that would indicate a real problem.

Comment 3 GitLab Migration User 2019-05-10 15:54:24 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/727.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.