bug#71744: 29.4; SIGSEGV during completion-at-point in lsp-mode with corfu and cape

[Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Pip Cet <pipcet@protonmail.com> writes:

> "Eli Zaretskii" <eliz@gnu.org> writes:
>
>>> Cc: 71744@debbugs.gnu.org
>>> Date: Wed, 14 Aug 2024 19:03:10 +0300
>>> From: Eli Zaretskii <eliz@gnu.org>
>>>
>>> > Date: Wed, 14 Aug 2024 15:40:34 +0000
>>> > From: Sigve Indregard <sigve.indregard@pm.me>
>>> > Cc: 71744@debbugs.gnu.org
>>> >
>>> > (gdb) frame 3
>>> > #3  parse_modifiers (symbol=XIL(0x5555564e3dc0)) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:6888
>>> > 6888	parse_modifiers (Lisp_Object symbol)
>>> > (gdb) print symbol
>>> > $11 = XIL(0x5555564e3dc0)
>>> > (gdb) xsymbol
>>> > $12 = (struct Lisp_Symbol *) 0xaaaaac1f1640
>>> > Cannot access memory at address 0xaaaaac1f1648
>>
>> Btw, this 0x5555564e3dc0 value is the same as the pointer to old_kbd
>> inside read_char:
>>
>>   #7  read_char (commandflag=0, map=0x0, prev_event=0x0, used_mouse_menu=0x0, end_time=0x7fffffffb5b0) at /usr/src/debug/emacs/emacs-29.4-wayland/src/keyboard.c:3018
>> 	  c = <optimized out>
>> 	  local_getcjmp = {{__jmpbuf = {93825000405056, -5147324661749537557, 1, 4611686019484352512, 5, 0, -5147324661946669845, -1313834696378178325}, __mask_was_saved = 0, __saved_mask = {__val = {0, 93825010269488, 93825104789632, 140737488335792, 18446744073709550936, 11, 93825104789616, 140737488335856, 140737279378894, 140737488335856, 140737488335920, 0, 140737488335920, 0, 93825010269488, 140737488336000}}}}
>> 	  save_jump = {{__jmpbuf = {12048, 140737188459256, 140737488335856, 93825095637120, 16, -7692597586030666240, 48, 1}, __mask_was_saved = 1453957408, __saved_mask = {__val = {140737488335776, 2, 140737488335824, 140737488335760, 140737321006214, 1, 140737321006651, 14319535557742690304, 6, 140737488335696, 140737279373914, 93825000331312, 0, 1, 1, 93823560581122}}}}
>> 	  tem = <optimized out>
>> 	  save = 0x0
>> 	  previous_echo_area_message = 0x0
>> 	  also_record = 0x0
>> 	  reread = false
>> 	  recorded = false
>> 	  polling_stopped_here = false
>> 	  orig_kboard = 0x5555564e3dc0  <<<<<<<<<<<<<<<<<<<<<<<
>>
>> So either the value of orig_kboard here is bogus (perhaps due to
>> optimizations), or somehow the variable C, which is supposed to hold
>> an input event, holds something very different instead, and then it's
>> a small surprise that we crash.
>
> I think this looks like a setjmp-related bug. If this sys_setjmp in
> read_char:
>
>   specpdl_ref jmpcount = SPECPDL_INDEX ();
>   if (sys_setjmp (local_getcjmp))
>     {
>       /* Handle quits while reading the keyboard.  */
>
> returns true, we goto non_reread, where we test NILP (c). However, 'c'
> is not declared volatile, and it might have changed, which would lead to
> undefined behavior, including the possibility of holding another value
> like orig_kboard.
>
> I'm afraid the only way to know for sure whether there's anything to
> that theory is to look at the output of "disass/rs read_char" in gdb,
> using the exact same binary that crashed, and check it line by line
> (about 3,000 lines here...)

I've done that now, and the bug is as I've described: the location
-0x4e8(%rbp) sometimes holds orig_kboard, but is assumed to hold 'c'
after a longjmp.

This should fix it:

diff --git a/src/keyboard.c b/src/keyboard.c
index b312d529e59..148b9ee4dbf 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2522,7 +2522,7 @@ read_char (int commandflag, Lisp_Object map,
 	   Lisp_Object prev_event,
 	   bool *used_mouse_menu, struct timespec *end_time)
 {
-  Lisp_Object c;
+  volatile Lisp_Object c;
   sys_jmp_buf local_getcjmp;
   sys_jmp_buf save_jump;
   Lisp_Object tem, save;


But it'd be really nice to recreate the buggy build and apply just this
patch and see whether that fixes things. Unfortunately, Arch builds are
very hard to reproduce precisely, so I'm not sure I can do it.

Pip