Yes, it looks like Michael's changes have nothing to do with this bug, but these seem just to reveal some undefined behavior... idk. Btw, just by commenting the line src/keyboard.c:11697, it is not crashing anymore; maybe this could be a hint. > gcc --version gcc (Debian 12.2.0-14) 12.2.0 > Can you check that 0x555555cf0b00 is a valid dpyinfo structure? (gdb) info locals event = 0x555555953aa0 copy = {kind = SELECTION_REQUEST_EVENT, dpyinfo = 0x55c82260, requestor = 0x555555f93a80, selection = 0x45, target = 0x4d, property = 0x5e, time = 0} moved_events = (gdb) x 0x555555c82260 0x555555c82260: 0x00 > Can you run "ptype/o struct selection_input_event" [...] (gdb) ptype/o struct selection_input_event /* offset | size */ type = struct selection_input_event { /* 0: 0 | 4 */ enum event_kind kind : 16; /* XXX 6-byte hole */ /* 8 | 8 */ struct pgtk_display_info *dpyinfo; /* 16 | 8 */ GdkWindow *requestor; /* 24 | 8 */ GdkAtom selection; /* 32 | 8 */ GdkAtom target; /* 40 | 8 */ GdkAtom property; /* 48 | 4 */ guint32 time; /* XXX 4-byte padding */ /* total size (bytes): 56 */ } (gdb) ptype/o struct input_event /* offset | size */ type = struct input_event { /* 0: 0 | 4 */ enum event_kind kind : 16; /* 2: 0 | 4 */ enum scroll_bar_part part : 16; /* 4 | 4 */ unsigned int code; /* 8 | 4 */ unsigned int modifiers; /* XXX 4-byte hole */ /* 16 | 8 */ Lisp_Object x; /* 24 | 8 */ Lisp_Object y; /* 32 | 8 */ Time timestamp; /* 40 | 8 */ Lisp_Object frame_or_window; /* 48 | 8 */ Lisp_Object arg; /* 56 | 8 */ Lisp_Object device; /* total size (bytes): 64 */ } (gdb) ptype/o union buffered_input_event /* offset | size */ type = union buffered_input_event { /* 4 */ enum event_kind kind : 16; /* 64 */ struct input_event { /* 0: 0 | 4 */ enum event_kind kind : 16; /* 2: 0 | 4 */ enum scroll_bar_part part : 16; /* 4 | 4 */ unsigned int code; /* 8 | 4 */ unsigned int modifiers; /* XXX 4-byte hole */ /* 16 | 8 */ Lisp_Object x; /* 24 | 8 */ Lisp_Object y; /* 32 | 8 */ Time timestamp; /* 40 | 8 */ Lisp_Object frame_or_window; /* 48 | 8 */ Lisp_Object arg; /* 56 | 8 */ Lisp_Object device; /* total size (bytes): 64 */ } ie; /* 56 */ struct selection_input_event { /* 0: 0 | 4 */ enum event_kind kind : 16; /* XXX 6-byte hole */ /* 8 | 8 */ struct pgtk_display_info *dpyinfo; /* 16 | 8 */ GdkWindow *requestor; /* 24 | 8 */ GdkAtom selection; /* 32 | 8 */ GdkAtom target; --Type for more, q to quit, c to continue without paging-- /* 40 | 8 */ GdkAtom property; /* 48 | 4 */ guint32 time; /* XXX 4-byte padding */ /* total size (bytes): 56 */ } sie; /* total size (bytes): 64 */ } On Wed, 26 Feb 2025 at 18:08, Pip Cet wrote: > "Iurie Marian" writes: > > > Dear Maintainers, > > > > Emacs is crashing while copying-as-kill/killing-word, only when compiled > > with -O3 optimizations. I am using PGTK (see the configure command > > below). I did a git bisect, and it seems that the commit below is > > triggering the bug. To reproduce it just compile with -O3 and PGTK, then > > simply hit M-. > > Just for completeness, you're using lto as well as -O3, which seems more > likely to trigger this bug than Michael's change below. > > And I can't reproduce it here. > > Which precise compiler are you using? gcc --version would be very > helpful here. > > > (gdb) list > > 566 pushed = false; > > 567 > > 568 if (!dpyinfo) > > 569 goto DONE; > > 570 > > 571 local_selection_data = LOCAL_SELECTION (selection_symbol, > dpyinfo); > > 572 > > 573 /* Decline if we don't own any selections. */ > > 574 if (NILP (local_selection_data)) goto DONE; > > 575 > > > > (gdb) fr 2 > > #2 process_special_events () at > > /home/rce/.local/emacs/sources/src/keyboard.c:4570 > > 4570 pgtk_handle_selection_event (©); > > (gdb) list > > 4565 input_pending = readable_events (0); > > 4566 > > 4567 #ifdef HAVE_X11 > > 4568 x_handle_selection_event (©); > > 4569 #else > > 4570 pgtk_handle_selection_event (©); > > 4571 #endif > > 4572 #elif defined HAVE_HAIKU > > 4573 if (event->ie.kind != SELECTION_CLEAR_EVENT) > > 4574 emacs_abort (); > > (gdb) info locals > > event = 0x555555957a40 > > copy = {kind = SELECTION_REQUEST_EVENT, dpyinfo = 0x55cf0b00, > > dypinfo looks like it was truncated to 32 bits. Can you check that > 0x555555cf0b00 is a valid dpyinfo structure? > > The definition in question is: > > struct selection_input_event > { > ENUM_BF (event_kind) kind : EVENT_KIND_WIDTH; > struct pgtk_display_info *dpyinfo; > /* We spell it with an "o" here because X does. */ > GdkWindow *requestor; > GdkAtom selection, target, property; > guint32 time; > }; > > Can you run "ptype/o struct selection_input_event" and "ptype/o struct > input_event" to see what might be going on? "ptype/o union > buffered_input_event" would also be interesting, to see whether our > union trick might no longer be working. > > Pip > >