Bug 107672 - Complete freeze if breakpoint is placed in gtk signal handler
Summary: Complete freeze if breakpoint is placed in gtk signal handler
Status: RESOLVED MOVED
Alias: None
Product: Wayland
Classification: Unclassified
Component: XWayland (show other bugs)
Version: 1.0.x
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-24 06:13 UTC by Gunter Königsmann
Modified: 2019-05-10 15:54 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

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.