30.0.50; PGTK copy + paste to other app problem

Hello dear maintainers!

I use pgtk emacs on wayland (sway) and a few months ago started facing a

problem with copy/pasting to ungoogled-chromium. Tried to find relevant

reports on bug-gun-emacs, but didn't succeed.

Way to reproduce and observed behavior:

0. guix shell emacs-next-pgtk (or build a fresh emacs with pgtk from master).

1. Launch emacs -Q.

2. Select any text and optionally copy it with M-w.

3. Paste it to chromium address bar with middle mouse or C-v if it was

copied with M-w.

4. Both chromium and emacs get frozen for some time.

5. After some time Emacs crashes, chromium unfreezes.

6. A few times I saw "waiting for reply from selection owner." in emacs

echo area, but can't reproduce it right now.

- The same workflow, but with foot terminal instead of emacs works fine.

- The same version of Emacs, but built without PGTK, works fine too:

guix shell emacs-next-tree-sitter -- emacs -Q

- Copy pasting from emacs-next-pgtk to alacritty and icecat works fine.

The report of this problem on bug-guix and a backtrace of segfault:

A temporary workaround we use (it solves M-w + C-v, but not selection +

middle mouse):

Let me know if I can provide any additional information or testing.

In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version

3.24.30, cairo version 1.16.0)

System Description: Guix System

Configured using:

'configure

CONFIG_SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash

SHELL=/gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash

--prefix=/gnu/store/701xsj5ngwasz7i962q5mdyqklvfhvx0-emacs-next-pgtk-30.0.50-0.ac7ec87

--enable-fast-install --with-pgtk --with-modules --with-cairo

--with-native-compilation --disable-build-details'

Configured features:

ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG

JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NATIVE_COMP

NOTIFY INOTIFY PDUMPER PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF

TOOLKIT_SCROLL_BARS TREE_SITTER XIM GTK3 ZLIB

Important settings:

value of $EMACSLOADPATH: /home/bob/.guix-home/profile/share/emacs/site-lisp:/gnu/store/701xsj5ngwasz7i962q5mdyqklvfhvx0-emacs-next-pgtk-30.0.50-0.ac7ec87/share/emacs/30.0.50/lisp:/gnu/store/701xsj5ngwasz7i962q5mdyqklvfhvx0-emacs-next-pgtk-30.0.50-0.ac7ec87/share/emacs/30.0.50/lisp

value of $EMACSNATIVELOADPATH: /home/bob/.guix-home/profile/lib/emacs/native-site-lisp

value of $LANG: en_US.utf8

locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:

tooltip-mode: t

global-eldoc-mode: t

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

global-font-lock-mode: t

font-lock-mode: t

blink-cursor-mode: 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

Memory information:

((conses 16 77880 5562)

(symbols 48 7125 0)

(strings 32 19872 2975)

(string-bytes 1 650293)

(vectors 16 16564)

(vector-slots 8 328550 6303)

(floats 8 27 24)

(intervals 56 222 0)

(buffers 984 11))

--

Best regards,

Andrew Tropin

Andrew Tropin <andrew@trop.in> writes:

Unfortunately, the backtrace is not helpful, because it does not include

symbols from the crashing Emacs.

Would you please run Emacs under GDB and reproduce the crash there?

Then, when Emacs crashes, type:

(gdb) bt

then type return, and send the output here. Thanks.

On 2023-03-20 19:05, Po Lu wrote:

Sure!

--

Best regards,

Andrew Tropin

Andrew Tropin <andrew@trop.in> writes:

Thanks. What this says is that GDK has emitted an event, which is being

dispatched to what it thinks is a widget, but either the widget's signal

handler or the widget itself is invalid, causing GObject to crash during

signal dispatch.

Would you please install debuginfo for libgdk-3.so.0, libgtk-3.so.0 and

libgobject-2.0.so.0 (I'm not sure how to this in the GuixSD) and try to

figure out what event is causing the crash?

I suggest going up to frame #12 and typing:

(gdb) p *event

after the debuginfo is installed and loaded by GDB.

On 2023-03-20 20:36, Po Lu wrote:

Sorry for the long response, I was figuring out some GDB settings :)

For the record and maybe future readers, my ~/.gdbinit:

I run gdb the following way:

guix shell gdb glib:debug gtk+:debug emacs-next-pgtk \

--with-debug-info=emacs-next-pgtk -- \

gdb --args sh -c 'exec emacs -Q'

The result I got:

It complains `No symbol "event" in current context.`, am I did something

wrong?

--

Best regards,

Andrew Tropin

Andrew Tropin <andrew@trop.in> writes:

Yes, you didn't get debug information loaded in GDB.

What does:

(gdb) info sharedlibrary

say?

On 2023-03-21 18:30, Po Lu wrote:

On 2023-03-21 18:30, Po Lu wrote:

Ok, with the help of apteryx, I was able to figure it out, there were a

problem in grafts mechanism, so A proper command is:

guix shell gdb emacs-next-pgtk --with-debug-info=emacs-next-pgtk \

--with-debug-info=gtk+ --with-debug-info=glib --no-grafts

The output is here:

Thank you for your patience :)

--

Best regards,

Andrew Tropin

Andrew Tropin <andrew@trop.in> writes:

OK, thanks. This is quite odd. If you type:

(gdb) p G_OBJECT_TYPE_NAME (widget)

what do you see?

On 2023-03-22 08:39, Po Lu wrote:

(gdb) p G_OBJECT_TYPE_NAME (widget)

No symbol "G_OBJECT_TYPE_NAME" in current context.

--

Best regards,

Andrew Tropin

Andrew Tropin <andrew@trop.in> writes:

Hmm. Would you please try this instead?

(gdb) p g_type_name (((GTypeInstance *) widget)->g_class->g_type)

On 2023-03-22 14:11, Po Lu wrote:

(gdb) p g_type_name (((GTypeInstance *) widget)->g_class->g_type)

'g_type_name' has unknown return type; cast the call to its declared return type

--

Best regards,

Andrew Tropin

Andrew Tropin <andrew@trop.in> writes:

Ah, I guess you have to cast it to (char *):

(gdb) p (char *) g_type_name ...

On 2023-03-22 18:33, Po Lu wrote:

(gdb) p (char *) g_type_name (((GTypeInstance *) widget)->g_class->g_type)

$1 = 0x7ffff7a6dda2 "GtkWindow"

--

Best regards,

Andrew Tropin

Andrew Tropin <andrew@trop.in> writes:

OK, thanks. Would you please type the following:

(gdb) p widget

(gdb) p Vframe_list

(gdb) xcar

(gdb) xframe

$N = ...

(gdb) p *$N->output.pgtk

thanks.

On 2023-03-23 08:44, Po Lu wrote:

(gdb) frame 12

#12 0x00007ffff798ac04 in gtk_widget_event_internal (widget=widget@entry=0xf04510, even7808 in gtkwidget.c

(gdb) p widget

$2 = (GtkWidget *) 0xf04510

(gdb) p Vframe_list

'Vframe_list' has unknown type; cast it to its declared type

(gdb) xcar

Undefined command: "xcar". Try "help".

(gdb) xframe

Undefined command: "xframe". Try "help".

--

Best regards,

Andrew Tropin

To solve the last two problems, do this:

(gdb) source /path/to/emacs/src/.gdbinit

These are commands we define in .gdbinit which comes with Emacs.

On 2023-03-23 09:16, Eli Zaretskii wrote:

Thank you very much. I updated my debugging setup and will write down a

note for future readers of this thread:

Downloaded latest emacs source code.

guix shell -D emacs-next-pgtk --with-debug-info=glib \

--with-debug-info=gtk+ --no-grafts -- \

./configure --enable-checking='yes,glyphs' \

--enable-check-lisp-object-type --with-pgtk \

CFLAGS='-O0 -g3'

guix shell -D emacs-next-pgtk --with-debug-info=glib \

--with-debug-info=gtk+ --no-grafts -- make

cd src

gdb emacs

--

Best regards,

Andrew Tropin

Andrew Tropin <andrew@trop.in> writes:

You forgot:

(gdb) p *$4->output_data.pgtk

Thanks.

On 2023-03-24 09:00, Po Lu wrote:

Right, completely forgot about this one :)

--

Best regards,

Andrew Tropin

Andrew Tropin <andrew@trop.in> writes:

So, the window which is getting this focus in event is 0x1014500, which

is not any window created by Emacs, assuming that you have only one

frame.

Perhaps this is a pseudo window created by the GDK Wayland backend to

``send'' selection requests to Emacs.

Would you please:

(gdb) p (GdkWindow *) gtk_widget_get_window ((GtkWidget *) 0x1014500);

$NN = ...

and then:

(gdb) p (GdkWindowType) gdk_window_get_window_type ($NN);

thanks.

On 2023-03-24 15:51, Po Lu wrote:

I restart the debbugger every time because otherwise my clipboard is

"locked", so the widget from p widget and from output_data.pgtk are the

same. Sorry for the confusion.

Additional info about the actions I do:

run emacs -Q

copy text from scratch buffer

try to insert in chromium address bar

C-g on frozen emacs

Try to toggle full screen frozen chromium

Emacs usually crashes with seg fault we are exploring right now

It seems there are some timeouts involved, because it reproduces from

time to time: sometimes it unfreezes both chromium and emacs without

crash (at least immediate crash), sometimes it crashes differently (can

show logs if you want).

--

Best regards,

Andrew Tropin

Andrew Tropin <andrew@trop.in> writes:

Right, thanks for clarifying that.

Perhaps this crash is not related to the widget being destroyed.

If you install debuginfo and debug source for libgobject, then type `l',

where does it show the crash occurs?

tags 62291 + moreinfo

thanks

Po Lu <luangruo@yahoo.com> writes:

Ping. Andrew, did you get any further with this?

On 2023-09-11 17:11, Stefan Kangas wrote:

I couldn't get debug symbols for libgobject, probably cause of grafts

and kinda gave up on this issue, sorry.

For the whole time we were using this fix in rde:

And recently (a few minutes ago) I found out that the problem

dissapeared, so I don't need this fix anymore. IDK, if it is due to

chromium version update or emacs.

Thank you very much for pinging! :)

I will report further in case it reappears.

--

Best regards,

Andrew Tropin

Andrew Tropin <andrew@trop.in> writes:

Great, and thank you for reporting back.

I'm therefore closing this bug report.

Please do, thanks in advance.