GNOME Bugzilla – Bug 719314
gdk_property_change segfault on multiple X protocol screens setup when X selection changed
Last modified: 2014-02-21 02:49:20 UTC
Maybe related: Bug 709716 Environment: 1. gtk+ 3.10.4, patched with commit 1d2a070254a2f01de3202392a8fdb43fc2ee84d2 2. multiple X screen setup (different screens have different DISPLAY env varible) Steps to reproduce: 1. run gtk3-demo (with DISPLAY=:0.0) 2. select some text in "Info" text area 3. yank the text into another window (by middle-button click) on other X screen (DISPLAY=:0.1) Backtrace: $ gdb --args gtk3-demo --gdk-debug=all 24: interval=117.8 paint_start=0.0 frame_end=6.3 predicted=16.7 Gdk-Message: selection request: window: 75498676 Program received signal SIGSEGV, Segmentation fault. 0x00007ffff74592d0 in gdk_property_change () from /usr/lib/libgdk-3.so.0 (gdb) bt
+ Trace 232834
I can reproduce the bug with many other gtk3 applications, including gnome-terminal and gnome-system-monitor. With an clipboard manager running in the background (such as fcitx), the foreground gtk3 application will crash immediately during the text selection step.
I reproduced this with liferea using gtk+ 3.10.5, similar circumstances. Select "copy URL to clipboard" and try to paste it into a browser on the other display. (liferea:28730): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed Program received signal SIGSEGV, Segmentation fault. gdk_property_change (window=0x0, property=0x72, type=0x46, format=8, mode= GDK_PROP_MODE_REPLACE, data=0xd05df0 "https://community.shaw.ca/community/forums/service-alerts/saskatchewan", nelements=70) at gdkwindow.c:10631 10631 gdkwindow.c: No such file or directory. (gdb) bt
+ Trace 232846
I've traced this down to _gdk_x11_display_screen_for_xrootwin returning NULL when the display is on a foreign screen. gdk_x11_window_foreign_new_for_display then returns NULL, resulting in event->selection.requestor being set to NULL in gdk_check_wm_desktop_changed, which ends up being the window parameter to gdk_property_change at the bottom of the call chain. I tried editing gdk_property_change to avoid dereferencing the "window" parameter when it's NULL, but then it crashes in _gdk_x11_display_send_selection_notify on dereferencing requestor. Fixing this dereference avoided the demo crashing, but the paste into the other screen is non-functional and the demo hits another assertion: (gtk3-demo:18332): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed I also separately tried reverting parts of 47a8c2f73302c88f8ef6daa08d3de625c18923d4 and a6b29d73d7ebbbe17ca0e4d1fd267754efc8cabf to try to make _gdk_x11_display_screen_for_xrootwin return a valid GdkScreen pointer, but I'm not familiar enough with the GTK+ sources to follow that logic. Hopefully this will help somebody more knowledgeable provide a proper fix.
commit c7c4b0c5fddb6b9d1e4c79c18f5b2a2c82e0bb77 Author: Benjamin Otte <otte@redhat.com> Date: Fri Dec 13 16:22:04 2013 +0100 clipboard: Don't crash when data is requested from NULL window This could happen if data was requested from a separate screen now that multi-screen is no longer supported. Ideally, we'd want to support copying to other screens, but that requires solving in GDK as that's X-specific so cannot be well abstracted by GDK (without the reintroduction of multiple screens).
Thank you for your quick fix. I will test this fix on my main machine tomorrow. May I ask why the support for X multiple screens was removed from GDK by commit 47a8c2f73302c88f8ef6daa08d3de625c18923d4 ? I mean what are the benefits by this change. I know multiple screens setup is a rare case. But X11 haven't changed for more than 20 years, and multiple screens will be still there until xrandr finally can do whatever multiple screens have done (which is false currently). Is there any feature that is made possible by this change? Thank you
There were 2 reasons: (1) Developers where confused about what a "screen" is when reading the GDK documentation. It was confused with monitors quite often. So they often wrote confusing or just plain wrong code which increased the number of bugs. (2) We want to simplify the codebase. And screens are a definite candidate for removal (GdkScreen and GdkDisplay will be merged into a single object at some point so that we can remove the other one with GTK 4.0). And now that we are doing the Wayland transition in both GTK and most of the applications based on it, it is a good time to do that change as most of the code that used to involve screens will now be revisited by developers for compatibility.
Thank you. I hope that wayland will be a final solution for multiple GPU/monitors setup.
Oh, one more comment: We hoped to not have any feature regressions even on X by removing screens. We assumed that you could instead use multiple GdkDisplays - ie opening a connection to :0.0 and to :0.1 and using their respective default screens. And this does work for most things. The clipboard case is the first one that came up that doesn't work. And I don't have a fix yet, but I consider it a regression that I intend to fix.
I am very glad to hear that the clipboard case will be fixed in the future. Thank you very much.
(In reply to comment #7) > The clipboard case is the first one that came up that doesn't work. And I don't > have a fix yet, but I consider it a regression that I intend to fix. Thank you for the fix. Should another bug be opened to track progress on the resulting regression?
(In reply to comment #9) > > Thank you for the fix. Should another bug be opened to track progress on the > resulting regression? Is that the regression where you can't copy/paste across screens any more? If so, did you file a bug and if yes, what's the bug number?
> Is that the regression where you can't copy/paste across screens any more? I can confirm that the regression is still in 3.10.7 (in archlinux's repo). I myself used a temp solution: bind super+ctrl+c to `xsel | xsel -bi`, which is useful even for programs that don't provide a copy command. > If so, did you file a bug and if yes, what's the bug number? I am not aware of any bug about this.
(In reply to comment #10) > Is that the regression where you can't copy/paste across screens any more? Correct. > If so, did you file a bug and if yes, what's the bug number? No, I did not.
(In reply to comment #11) > > I can confirm that the regression is still in 3.10.7 (in archlinux's repo). And still in F20. > I myself used a temp solution: bind super+ctrl+c to `xsel | xsel -bi`, which > is useful even for programs that don't provide a copy command. xsel hangs when I select text on screen :0.1 and then run xsel (on :0.0). It gets blocked in a poll: poll([{fd=3, events=POLLIN}], 1, 4294967295 fd 3 is undoubtedly the socket to the Xserver. If I select some text on :0.0 and run xsel on :0.0 I get the selected text. > I am not aware of any bug about this. So to be clear, is this an X11 bug or a gtk/gdk bug?
> xsel hangs when I select text on screen :0.1 and then run xsel (on :0.0). It > gets blocked in a poll: > > poll([{fd=3, events=POLLIN}], 1, 4294967295 > > fd 3 is undoubtedly the socket to the Xserver. > > If I select some text on :0.0 and run xsel on :0.0 I get the selected text. Same on archlinux. And I can confirm that if I run xsel on the same screen, it will behave normally. I always run xsel on the same screen with the gtk application. Therefore I didn't notice this bug until just then. > > I am not aware of any bug about this. > > So to be clear, is this an X11 bug or a gtk/gdk bug? Don't have enough knowledge to debug. I don't know.
Ahhh. So, if I select text on :0.1 and then run: $ DISPLAY=:0.1 xsel | xsel -pi I am able to middle-click paste on :0.0 and paste the selected text. Note the need to point the first xsel at :0.1 with the DISPLAY= variable setting. On the xsel on RHS of the pipe, I use "-pi" to put the selection into the clipboard where I can middle-click paste it since that is the easiest way to paste (compared to right click->paste, or ctrl+v, etc.).
(In reply to comment #10) > Is that the regression where you can't copy/paste across screens any more? > > If so, did you file a bug and if yes, what's the bug number? Someone else has reported the regression (inability to copy and paste across X protocol screens) as bug 721398
(In reply to comment #16) > (In reply to comment #10) > > Is that the regression where you can't copy/paste across screens any more? > > > > If so, did you file a bug and if yes, what's the bug number? > > Someone else has reported the regression (inability to copy and paste across X > protocol screens) as bug 721398 Lol. That was me. So many bugs I'm forgetting which ones I've opened tickets for. I notice it has not gotten any attention though other than somebody disagreeing with me that it's a blocker and it's just "normal".