bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

[David Welch]

[-- Attachment #1.1: Type: text/plain, Size: 7892 bytes --]

The bug doesn't seem to happen when running under Wayland.

To reproduce:-
1) Have xfreerdp (RDP client) running and connected to a remote system.
2) Run emacs on the same system as xfreerdp.
3) Copy some text to the kill ring.
4) Emacs crashes with an error.

(emacs:241123): Gdk-ERROR **: 14:26:18.002: The program 'emacs' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 2019 error_code 8 request_code 18 (core protocol) minor_code 0)

The call stack with (GDK_SYNCHRONIZE=1) is

#5  0x00007ffff776ed03 in gdk_x_error (error=0x7fffffffcf80, xdisplay=0x555555f23dc0) at ../../../../../gdk/x11/gdkmain-x11.c:307
#6  gdk_x_error (xdisplay=0x555555f23dc0, error=0x7fffffffcf80) at ../../../../../gdk/x11/gdkmain-x11.c:269
#7  0x00007ffff029528b in _XError (dpy=dpy@entry=0x555555f23dc0, rep=rep@entry=0x55555651c730) at ../../src/XlibInt.c:1491
#8  0x00007ffff0291ff7 in handle_error (dpy=0x555555f23dc0, err=0x55555651c730, in_XReply=<optimised out>) at ../../src/xcb_io.c:199
#9  0x00007ffff0292095 in handle_response (dpy=dpy@entry=0x555555f23dc0, response=0x55555651c730, in_XReply=in_XReply@entry=1) at ../../src/xcb_io.c:324
#10 0x00007ffff029301d in _XReply (dpy=dpy@entry=0x555555f23dc0, rep=rep@entry=0x7fffffffd140, extra=extra@entry=0, discard=discard@entry=1) at ../../src/xcb_io.c:634
#11 0x00007ffff028e7f1 in XSync (dpy=0x555555f23dc0, discard=discard@entry=0) at ../../src/Sync.c:44
#12 0x00007ffff028e88f in _XSyncFunction (dpy=<optimised out>) at ../../src/Synchro.c:35
#13 0x00007ffff026ed53 in XChangeProperty(dpy=0x555555f23dc0, w=w@entry=14680065, property=property@entry=717, type=type@entry=356, format=format@entry=8, mode=mode@entry=2, data=0x555556032498 "Emacs", nelements=5)
    at ../../src/ChProp.c:92
#14 0x00007ffff7770282 in _gdk_x11_window_change_property (window=0x555556648a50, property=0xb2, type=0x46, format=8, mode=GDK_PROP_MODE_APPEND, data=0x555556032498 "Emacs", nelements=5)
    at ../../../../../gdk/x11/gdkproperty-x11.c:556
#15 0x00005555558a89da in pgtk_reply_selection_request (event=0x7fffffffd430, dpyinfo=0x5555560232c0) at ../../src/pgtkselect.c:480
#16 0x00005555558a9134 in pgtk_handle_selection_request (event=0x7fffffffd430) at ../../src/pgtkselect.c:653
#17 0x00005555558a95cf in pgtk_handle_selection_event (event=0x7fffffffd430) at ../../src/pgtkselect.c:784
#18 0x00005555556ea4b4 in process_special_events () at ../../src/keyboard.c:4400
#19 0x00005555556ea507 in swallow_events (do_display=false) at ../../src/keyboard.c:4440
#20 0x00005555556e5ed6 in read_char (commandflag=1, map=XIL(0x5555567d7ec3), prev_event=XIL(0), used_mouse_menu=0x7fffffffd829, end_time=0x0) at ../../src/keyboard.c:2577
#21 0x00005555556f7755 in read_key_sequence (keybuf=0x7fffffffda60, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false)
--Type <RET> for more, q to quit, c to continue without paging--
    at ../../src/keyboard.c:9984
#22 0x00005555556e29ba in command_loop_1 () at ../../src/keyboard.c:1382
#23 0x00005555557ab7e2 in internal_condition_case (bfun=0x5555556e25bc <command_loop_1>, handlers=XIL(0x90), hfun=0x5555556e1b85 <cmd_error>) at ../../src/eval.c:1485
#24 0x00005555556e225d in command_loop_2 (handlers=XIL(0x90)) at ../../src/keyboard.c:1132
#25 0x00005555557aadfc in internal_catch (tag=XIL(0xf720), func=0x5555556e2232 <command_loop_2>, arg=XIL(0x90)) at ../../src/eval.c:1208
#26 0x00005555556e21ed in command_loop () at ../../src/keyboard.c:1110
#27 0x00005555556e170e in recursive_edit_1 () at ../../src/keyboard.c:719
#28 0x00005555556e18c0 in Frecursive_edit () at ../../src/keyboard.c:802
#29 0x00005555556dda35 in main (argc=1, argv=0x7fffffffdf08) at ../../src/emacs.c:2517


I dug into this a bit and what seems to happen is emacs calls gdk_x11_window_change_property twice for the same window.

gdk_property_change (window=0x555556648a50, property=0xb2, type=0x4, format=32, mode=GDK_PROP_MODE_APPEND, data=0x5555564bc510 "\260", nelements=26)
gdk_property_change (window=0x555556648a50, property=0xb2, type=0x46, format=8, mode=GDK_PROP_MODE_APPEND, data=0x555556032498 "Emacs", nelements=5)

once to set a list of atoms and again to set a utf8 string. freerdp doesn't delete the property in between and this causes the X error because the data type doesn't match when using GDK_PROP_MODE_APPEND.

I've attached a small 'C' file that reproduces the same crash if it is run after emacs has copied some text to the kill ring.

It seems to have started happening after git commit be35c92c90d455739a6ff9d4beefa2b35d044852.



In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
 of 2022-07-27 built on LXP-D-WELCH
Repository revision: 186429888981fb818624847f7356908f253b1bda
Repository branch: master
System Description: Ubuntu 20.04.4 LTS

Configured using:
 'configure --prefix=/home/dwelch/devel/emacs/install --with-x=yes
 --with-x-toolkit=gtk3 --with-xwidgets=yes --with-pgtk=yes
 --with-modules=yes 'CFLAGS=-O0 -g''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY
PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS XIM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  isearch-fold-quotes-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date subr-x
cl-loaddefs cl-lib mule-util info rmc iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/pgtk-win pgtk-win term/common-win pgtk-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch
easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal dbusbind
inotify dynamic-setting system-font-setting font-render-setting cairo
gtk pgtk lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 48913 7812)
 (symbols 48 5398 0)
 (strings 32 17165 2055)
 (string-bytes 1 501071)
 (vectors 16 10839)
 (vector-slots 8 161927 12638)
 (floats 8 67 35)
 (intervals 56 492 0)
 (buffers 992 12))


[-- Attachment #1.2: Type: text/html, Size: 10208 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: xclip.c --]
[-- Type: text/x-csrc; name="xclip.c", Size: 4201 bytes --]

#include <stdio.h>
#include <X11/Xatom.h>
#include <X11/Xlib.h>

void show_targets(Display *dpy, Window w, Atom p)
{
        Atom type, *targets;
        int di;
        unsigned long i, nitems, dul;
        unsigned char *prop_ret = NULL;
        char *an = NULL;

        /* Read the first 1024 atoms from this list of atoms. We don't
         * expect the selection owner to be able to convert to more than
         * 1024 different targets. :-) */
        XGetWindowProperty(dpy, w, p, 0, 1024 * sizeof(Atom), False, XA_ATOM,
                           &type, &di, &nitems, &dul, &prop_ret);

        printf("Targets:\n");
        targets = (Atom *)prop_ret;
        for (i = 0; i < nitems; i++)
        {
                an = XGetAtomName(dpy, targets[i]);
                printf("    '%s'\n", an);
                if (an)
                        XFree(an);
        }
        XFree(prop_ret);

        //XDeleteProperty(dpy, w, p);
}

void show_utf8_prop(Display *dpy, Window w, Atom p)
{
        Atom da, incr, type;
        int di;
        unsigned long size, dul;
        unsigned char *prop_ret = NULL;

        /* Dummy call to get type and size. */
        XGetWindowProperty(dpy, w, p, 0, 0, False, AnyPropertyType,
                           &type, &di, &dul, &size, &prop_ret);
        XFree(prop_ret);

        incr = XInternAtom(dpy, "INCR", False);
        if (type == incr)
        {
                printf("Data too large and INCR mechanism not implemented\n");
                return;
        }

        /* Read the data in one go. */
        printf("Property size: %lu\n", size);

        XGetWindowProperty(dpy, w, p, 0, size, False, AnyPropertyType,
                           &da, &di, &dul, &dul, &prop_ret);
        printf("%s", prop_ret);
        fflush(stdout);
        XFree(prop_ret);

        /* Signal the selection owner that we have successfully read the
         * data. */
        XDeleteProperty(dpy, w, p);
}

int main()
{
        Display *dpy;
        Window target_window, root;
        int screen;
        Atom sel, targets, target_property, utf8;
        XEvent ev;
        XSelectionEvent *sev;

        dpy = XOpenDisplay(NULL);
        if (!dpy)
        {
                fprintf(stderr, "Could not open X display\n");
                return 1;
        }

        screen = DefaultScreen(dpy);
        root = RootWindow(dpy, screen);

        sel = XInternAtom(dpy, "CLIPBOARD", False);
        targets = XInternAtom(dpy, "TARGETS", False);
        utf8 = XInternAtom(dpy, "UTF8_STRING", False);
        target_property = XInternAtom(dpy, "PENGUIN", False);

        target_window = XCreateSimpleWindow(dpy, root, -10, -10, 1, 1, 0, 0, 0);

        XConvertSelection(dpy, sel, targets, target_property, target_window,
                          CurrentTime);

        int stage = 0;
        for (;;)
        {
                XNextEvent(dpy, &ev);
                switch (ev.type)
                {
                case SelectionNotify:
                        sev = (XSelectionEvent *)&ev.xselection;
                        if (sev->property == None)
                        {
                                printf("Conversion could not be performed.\n");
                                return 1;
                        }
                        else
                        {
                                if (stage == 0)
                                {
                                        show_targets(dpy, target_window, target_property);

                                        /* Request conversion to UTF-8. Not all owners will be able to fulfill that request. */
                                        XConvertSelection(dpy, sel, utf8, target_property, target_window, CurrentTime);

                                        stage = 1;
                                }
                                else
                                {
                                        show_utf8_prop(dpy, target_window, target_property);
                                        return 0;
                                }
                                
                        }
                        break;
                }
        }
}

bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

David Welch <davidwelch158@hotmail.com> writes:

> The bug doesn't seem to happen when running under Wayland. 
>
> To reproduce:-
> 1) Have xfreerdp (RDP client) running and connected to a remote system.
> 2) Run emacs on the same system as xfreerdp.
> 3) Copy some text to the kill ring.
> 4) Emacs crashes with an error.
>
> (emacs:241123): Gdk-ERROR **: 14:26:18.002: The program 'emacs' received an X Window System error. 
> This probably reflects a bug in the program.
> The error was 'BadMatch (invalid parameter attributes)'.
>   (Details: serial 2019 error_code 8 request_code 18 (core protocol) minor_code 0)
>
> The call stack with (GDK_SYNCHRONIZE=1) is 
>
> #5  0x00007ffff776ed03 in gdk_x_error (error=0x7fffffffcf80, xdisplay=0x555555f23dc0) at ../../../../../gdk/x11/gdkmain-x11.c:307 
> #6  gdk_x_error (xdisplay=0x555555f23dc0, error=0x7fffffffcf80) at ../../../../../gdk/x11/gdkmain-x11.c:269
> #7  0x00007ffff029528b in _XError (dpy=dpy@entry=0x555555f23dc0, rep=rep@entry=0x55555651c730) at ../../src/XlibInt.c:1491
> #8  0x00007ffff0291ff7 in handle_error (dpy=0x555555f23dc0, err=0x55555651c730, in_XReply=<optimised out>) at ../../src/xcb_io.c:199
> #9  0x00007ffff0292095 in handle_response (dpy=dpy@entry=0x555555f23dc0, response=0x55555651c730, in_XReply=in_XReply@entry=1) at ../../src/xcb_io.c:324
> #10 0x00007ffff029301d in _XReply (dpy=dpy@entry=0x555555f23dc0, rep=rep@entry=0x7fffffffd140, extra=extra@entry=0, discard=discard@entry=1) at
> ../../src/xcb_io.c:634
> #11 0x00007ffff028e7f1 in XSync (dpy=0x555555f23dc0, discard=discard@entry=0) at ../../src/Sync.c:44
> #12 0x00007ffff028e88f in _XSyncFunction (dpy=<optimised out>) at ../../src/Synchro.c:35 
> #13 0x00007ffff026ed53 in XChangeProperty(dpy=0x555555f23dc0, w=w@entry=14680065, property=property@entry=717, type=type@entry=356,
> format=format@entry=8, mode=mode@entry=2, data=0x555556032498 "Emacs", nelements=5)
>     at ../../src/ChProp.c:92
> #14 0x00007ffff7770282 in _gdk_x11_window_change_property (window=0x555556648a50, property=0xb2, type=0x46, format=8,
> mode=GDK_PROP_MODE_APPEND, data=0x555556032498 "Emacs", nelements=5)
>     at ../../../../../gdk/x11/gdkproperty-x11.c:556

The PGTK build does not support X11, so you should build without PGTK
enabled.  This crash is known to happen there, and will not be fixed,
since adding 300-400 lines of X specific selection code to the PGTK port
seems very irrational for a platform that it is not intended to support.

Closing, thanks.

bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

[David Welch]

[-- Attachment #1: Type: text/plain, Size: 938 bytes --]

The non-official Ubuntu packages for the latest emacs versions started using --with-pgtk in May. https://git.launchpad.net/~ubuntu-elisp/emacs/commit/?id=d21840558db7324543b9afa46b453b376a812720

Of interest, what's the reason for not using GDK_PROP_MODE_REPLACE when setting the property in response to a selection request?

________________________________
From: Po Lu <luangruo@yahoo.com>
Sent: 27 July 2022 14:49
To: David Welch <davidwelch158@hotmail.com>
Cc: 56792-done@debbugs.gnu.org <56792-done@debbugs.gnu.org>
Subject: Re: bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

The PGTK build does not support X11, so you should build without PGTK
enabled.  This crash is known to happen there, and will not be fixed,
since adding 300-400 lines of X specific selection code to the PGTK port
seems very irrational for a platform that it is not intended to support.

Closing, thanks.

[-- Attachment #2: Type: text/html, Size: 2514 bytes --]

bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

David Welch <davidwelch158@hotmail.com> writes:

> The non-official Ubuntu packages for the latest emacs versions started
> using --with-pgtk in May.
> https://git.launchpad.net/~ubuntu-elisp/emacs/commit/?id=d21840558db7324543b9afa46b453b376a812720

Please ask them to stop.

> Of interest, what's the reason for not using GDK_PROP_MODE_REPLACE
> when setting the property in response to a selection request?

No reason in particular, the code is just kept closer to xselect.c.

bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

[David Welch]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Are you sure? It looks to me like it uses replace except for the case of INCR (which isn't implemented in pgtkselect.c).

for (cs = frame->converted_selections; cs; cs = cs->next)
{
if (cs->property == None)
continue;
bytes_remaining = cs->size;
bytes_remaining *= cs->format >> 3;
if (bytes_remaining <= max_bytes)
{
/* Send all the data at once, with minimal handshaking. */
TRACE1 ("Sending all %"pD"d bytes", bytes_remaining);
XChangeProperty (display, window, cs->property,
cs->type, cs->format, PropModeReplace,
cs->data, cs->size);
}

________________________________
From: Po Lu <luangruo@yahoo.com>
Sent: 28 July 2022 01:39
To: David Welch <davidwelch158@hotmail.com>
Cc: 56792-done@debbugs.gnu.org <56792-done@debbugs.gnu.org>
Subject: Re: bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

> Of interest, what's the reason for not using GDK_PROP_MODE_REPLACE
> when setting the property in response to a selection request?

No reason in particular, the code is just kept closer to xselect.c.

[-- Attachment #2: Type: text/html, Size: 7875 bytes --]

bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

[Lars Ingebrigtsen]

Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@gnu.org> writes:

> The PGTK build does not support X11, so you should build without PGTK
> enabled.  This crash is known to happen there, and will not be fixed,
> since adding 300-400 lines of X specific selection code to the PGTK port
> seems very irrational for a platform that it is not intended to support.

Emacs shouldn't segfault, though.  It's fine to signal an error in this
situation, but segfaulting is not.

bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs@gnu.org> writes:
>
>> The PGTK build does not support X11, so you should build without PGTK
>> enabled.  This crash is known to happen there, and will not be fixed,
>> since adding 300-400 lines of X specific selection code to the PGTK port
>> seems very irrational for a platform that it is not intended to support.
>
> Emacs shouldn't segfault, though.  It's fine to signal an error in this
> situation, but segfaulting is not.

The segfault (which is really not a segfault, just GDK displaying a
window system error and aborting in an unusual manner) is hard to avoid
without adding X specific error handling code
(gdk_x11_display_error_trap_push).  Which will then add a dependency on
the X11-specific parts of GDK, and won't work if Emacs did not see them
at build-time.

bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

> The segfault (which is really not a segfault, just GDK displaying a
> window system error and aborting in an unusual manner) is hard to avoid
> without adding X specific error handling code
> (gdk_x11_display_error_trap_push).  Which will then add a dependency on
> the X11-specific parts of GDK, and won't work if Emacs did not see them
> at build-time.

But aborting here is not acceptable.  Surely there's something Emacs can
do here -- it doesn't have to do something sensible, it just has to not
abort.

bug#56792: 29.0.50; Emacs crashes when selecting text if xfreerdp is also running

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But aborting here is not acceptable.  Surely there's something Emacs can
> do here -- it doesn't have to do something sensible, it just has to not
> abort.

GDK doesn't have a generic "window system error" concept, which is only
present on X11.  So unless you write error trapping code specific to
X11, there's no way to handle those errors.  And doing that isn't
reliable if the GDK X11 development files were not installed at
build-time.