Package: emacs;
Reported by: Iurie Marian <marian.iurie <at> gmail.com>
Date: Tue, 25 Feb 2025 17:34:01 UTC
Severity: normal
Merged with 76729
Found in version 31.0.50
Message #38 received at 76559 <at> debbugs.gnu.org (full text, mbox):
From: Iurie Marian <marian.iurie <at> gmail.com> To: Pip Cet <pipcet <at> protonmail.com> Cc: 76559 <at> debbugs.gnu.org Subject: Re: bug#76559: 31.0.50; [-O3 + PGTK] Crash when 'copying as kill'/'killing word' Date: Wed, 26 Feb 2025 21:11:57 +0100
[Message part 1 (text/plain, inline)]
> 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 <pipcet <at> protonmail.com> wrote:
> "Iurie Marian" <marian.iurie <at> gmail.com> 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
>
>
[Message part 2 (text/html, inline)]
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.