Subject: bug#76559: 31.0.50; [-O3 + PGTK] Crash when 'copying as kill'/'killing word'

From: Iurie Marian <[email-masked]>
Date: Wed, 26 Feb 2025 21:11:57 +0100

> Can you retry with x/64gx [...]

(gdb) info locals
event = 0x555555953aa0 <kbd_buffer+384>
copy = {kind = SELECTION_REQUEST_EVENT, dpyinfo = 0x55c84660, requestor =
0x555556038a80, selection = 0x45, target = 0x4d, property = 0x5e, time = 0}
moved_events = <optimized out>

(gdb) x/64gx 0x555555c84660
0x555555c84660: 0x0000000000000000      0x0000555555b05f28
0x555555c84670: 0x0000555555b7a000      0x0000000000000000
0x555555c84680: 0x00007fffef274083      0x0000000100000001
0x555555c84690: 0x0000555555c6d750      0x0000000300000006
0x555555c846a0: 0x0000000000000011      0x0000000000000000
0x555555c846b0: 0x0000000000000000      0x0000000000000000
0x555555c846c0: 0x4058000000000000      0x4058000000000000
0x555555c846d0: 0x0000002000000000      0x0000000000000001
0x555555c846e0: 0xffffffffffffffff      0x000000000000002a
0x555555c846f0: 0x0000000000000000      0x0000555555da3120
0x555555c84700: 0x0000555555da0d20      0xffffffffffffffff
0x555555c84710: 0xffffffff00000000      0x00000000ffffffff
0x555555c84720: 0x0000000000000000      0x0000000000000000
0x555555c84730: 0x0000000000000000      0x0000000000000000
0x555555c84740: 0x0000000000000000      0x0000000000000000
0x555555c84750: 0x0000555555b06178      0x0000555555b06178
0x555555c84760: 0x0000555555b06178      0x0000000000000000
0x555555c84770: 0x0000000000000000      0x0000000000000000
0x555555c84780: 0x0000000000000000      0x0000000000000000
0x555555c84790: 0x0000000000000000      0x000000000221256a
0x555555c847a0: 0x0000000000000000      0x0000555555d6ce40
0x555555c847b0: 0x0000555555c12aa0      0x0000555555c6dce0
0x555555c847c0: 0x0000000000000000      0x0000000000000000
0x555555c847d0: 0x0000555555e75b90      0x0000555555b06178
0x555555c847e0: 0x0000000000000000      0x0000000000000000
0x555555c847f0: 0x3ff0000000000000      0x3ff0000000000000
0x555555c84800: 0x0000000000000004      0x0000000000000021
0x555555c84810: 0x0000555555c0c360      0x00007ffff7fade20
0x555555c84820: 0x0000000000000000      0x0000000000000041
0x555555c84830: 0x0000555555c0fb00      0x0000555555c7bb40
0x555555c84840: 0x0000000000000000      0x0000555555c0faa0
0x555555c84850: 0x0000555555c80220      0x0000000000000000

I have just tried with gcc 14.2 and it works well - NO crash, although it
shows the same "6-byte hole" for `ptype/o struct selection_input_event`.

Kind Regards
Iurie

On Wed, 26 Feb 2025 at 19:47, Pip Cet <[email-masked]> wrote:

> "Iurie Marian" <[email-masked]> writes:
>
> > 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 <kbd_buffer+384>
> > copy = {kind = SELECTION_REQUEST_EVENT, dpyinfo = 0x55c82260, requestor
> = 0x555555f93a80, selection = 0x45, target = 0x4d, property =
> > 0x5e, time = 0}
> > moved_events = <optimized out>
> >
> > (gdb) x 0x555555c82260
> > 0x555555c82260: 0x00
>
> Well, that only tells us the first byte is 0, which is probably correct.
> Can you retry with x/64gx 0x555555c82260 (or the new address) so we see
> some more data?
>
> >> 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      */
>
> This is strange, but it looks like this may be a C undefined behavior
> bug (or, less likely, an actual GCC bug).  If the event_kind bitfield is
> listed with size 4, shouldn't the hole after it be listed with size 4,
> not size 6?
>
> Here's the code obtained by disass/s evq_flush which copies the relevant
> part of the header:
>
> 3810          *kbd_store_ptr = *event;
>    0x00000000002f9f4c <+108>:   movd   %xmm0,(%rdx)
>    0x00000000002f9f50 <+112>:   movdqa 0x20(%rsp),%xmm4
>    0x00000000002f9f56 <+118>:   movdqa 0x10(%rsp),%xmm5
>    0x00000000002f9f5c <+124>:   movq   %xmm1,0x4(%rdx)
>
> The first movd (not movq or movdq!) copies four bytes containing the
> event_kind.  The unaligned movq at +124 copies 8 bytes to bytes 4-11 of
> the struct, which copies the low-order 4 bytes of the dpyinfo.
>
> the code continues with:
>
>    0x00000000002f9f61 <+129>:   mov    %rax,0x1094e0(%rip)        #
> 0x403448 <kbd_store_ptr>
>    0x00000000002f9f68 <+136>:   sub    %rcx,%rax
>    0x00000000002f9f6b <+139>:   sar    $0x6,%rax
>    0x00000000002f9f6f <+143>:   mov    %r12,0x20(%rdx)
>    0x00000000002f9f73 <+147>:   mov    %rbp,0x38(%rdx)
>    0x00000000002f9f77 <+151>:   movups %xmm4,0x10(%rdx)
>    0x00000000002f9f7b <+155>:   movups %xmm5,0x28(%rdx)
>
> but, as far as I can tell, bytes 12-15 are never touched by this code.
>
> Here's the corresponding code which copies the event structure:
>
> 327           union buffered_input_event ev = evq->q[0];
>    0x00000000002f9fee <+270>:   lea    0x19a64b(%rip),%rcx        #
> 0x494640 <event_q.lto_priv.0>
>    0x00000000002f9ff5 <+277>:   mov    (%rcx),%rdi
>    0x00000000002f9ff8 <+280>:   movd   (%rdi),%xmm0
>    0x00000000002f9ffc <+284>:   movdqu 0x10(%rdi),%xmm2
>    0x00000000002fa001 <+289>:   movdqu 0x28(%rdi),%xmm3
>    0x00000000002fa006 <+294>:   movq   0x4(%rdi),%xmm1
>    0x00000000002fa00b <+299>:   mov    0x20(%rdi),%r12
>    0x00000000002fa00f <+303>:   mov    0x38(%rdi),%rbp
>    0x00000000002fa013 <+307>:   pextrw $0x0,%xmm0,%r13d
>    0x00000000002fa019 <+313>:   movaps %xmm2,0x20(%rsp)
>    0x00000000002fa01e <+318>:   movaps %xmm3,0x10(%rsp)
>
>
> Again, I see no code here which touches 0xc(%rdi) or the three bytes
> after it.
>
> But union buffered_input_event has no hole at bytes 12-15, only two of
> its union members do.
>
> So it seems this may be a bug with bitfield enums; it's not quite clear
> to me why we're using one here, but it doesn't seem to be working as
> intended.
>
> Pip
>
>