bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Date: Sat, 09 Feb 2019 00:55:41 +0000
>> 
>>    The following is printed to stderr, if Emacs was started from the
>>    terminal:
>>    
>>       *** longjmp causes uninitialized stack frame ***: ./src/emacs 
>> terminated
>>       Fatal error 6: Aborted
>
> This means we used a garbled or bogus jmp_buf contents, somehow.
>
>> 4. Also bizarely, when using non-optimized build, configured with:
>> 
>>       ./configure --enable-checking='yes,glyphs' \
>>       --enable-check-lisp-object-type CFLAGS='-O0 -g3 -gdwarf-4'
>> 
>>    I get _less_ information in gdb than when debugging an
>>    optimized build:
>>    
>>       (gdb) bt full
>>       #0  0x0000000000000000 in ?? ()
>>       No symbol table info available.
>>       #1  0x0000000000000000 in ?? ()
>>       No symbol table info available.
>>       (gdb) xbacktrace
>>       (gdb)
>
> I think the stack is smashed, so GDB is confused.
>
>> *** longjmp causes uninitialized stack frame ***: 
>> /home/capitaomorte/Source/Emacs/emacs-master/src/emacs terminated
>> 
>> Program received signal SIGABRT, Aborted.
>> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>> 50   ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>> (gdb) bt full
>> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
>>         set = {
>>           __val = {0, 0, 93825000843456, 140737328736549, 11310, 
>> 93825000838608, 93825000883760, 1, 140737488341936, 
>>             140737305084542, 93825008640256, 16777216000000000000, 
>> 140737488342240, 93825000373056, 4294967256, 1}
>>         }
>>         pid = <optimized out>
>>         tid = <optimized out>
>>         ret = <optimized out>
>> #1  0x00007ffff4f6d535 in __GI_abort () at abort.c:79
>>         save_stage = 1
>>         act = {
>>           __sigaction_handler = {
>>             sa_handler = 0x1, 
>>             sa_sigaction = 0x1
>>           }, 
>>           sa_mask = {
>>             __val = {140737305057658, 1937910009842106368, 
>> 8260008066545429248, 32, 1, 2, 140737488342496, 93825000021600, 
>>               140737488342544, 140737488342480, 140737305057352, 1, 
>> 140737305057658, 1937910009842106368, 140737488342400, 
>>               140737488342800}
>>           }, 
>>           sa_flags = -12928, 
>>           sa_restorer = 0x1000
>>         }
>>         sigs = {
>>           __val = {32, 0 <repeats 15 times>}
>>         }
>> #2  0x00007ffff4fc4718 in __libc_message (action=<optimized out>, 
>> fmt=fmt@entry=0x7ffff50cf088 "*** %s ***: %s terminated\n")
>>     at ../sysdeps/posix/libc_fatal.c:181
>>         ap = {{
>>             gp_offset = 32, 
>>             fp_offset = 465, 
>>             overflow_arg_area = 0x7fffffffcf20, 
>>             reg_save_area = 0x7fffffffceb0
>>           }}
>>         fd = 11
>>         list = <optimized out>
>>         nlist = <optimized out>
>>         cp = <optimized out>
>>         written = <optimized out>
>> #3  0x00007ffff5055bbd in __GI___fortify_fail_abort 
>> (need_backtrace=need_backtrace@entry=true, 
>>     msg=0x7ffff50cf03d <longjmp_msg> "longjmp causes uninitialized stack 
>> frame") at fortify_fail.c:28
>> No locals.
>> #4  0x00007ffff5055bf1 in __GI___fortify_fail (msg=<optimized out>) at 
>> fortify_fail.c:44
>> No locals.
>> #5  0x00007ffff5055aad in ____longjmp_chk () at 
>> ../sysdeps/unix/sysv/linux/x86_64/____longjmp_chk.S:105
>> No locals.
>> #6  0x00007ffff5055a0b in __longjmp_chk (env=0x555555d01238 
>> <main_thread+216>, val=val@entry=1) at ../setjmp/longjmp.c:39
>> No locals.
>> #7  0x00005555556b22d4 in quit_throw_to_read_char 
>> (from_signal=from_signal@entry=false) at keyboard.c:10486
>> No locals.
>> #8  0x00005555556ba3cd in set_waiting_for_input 
>> (time_to_clear=time_to_clear@entry=0x7fffffffd130) at keyboard.c:10253
>
> When this happens, what is the value of Vquit_flag, in Lisp terms?  Is
> it t or something else?

I can't tell exactly.  I believe this happens in *some* of the times I
ress C-g during the (while (sit-for)) in the following block extracted
from sly.el

This is the block.

   (catch catch-tag
       (sly-rex ()  ;; this sends something to an external process which
                    ;; will eventually "throw" via a process filter
           (sexp package)
         ((:ok value)
          (unless cancelled-on-input
            (throw catch-tag (list #'identity value))))
         ((:abort _condition)
          (throw catch-tag (list #'error "Synchronous Lisp Evaluation 
aborted"))))
       (cond (cancel-on-input
              (let ((inhibit-quit t))
                (unwind-protect
                    (while (sit-for 30))
                  (setq cancelled-on-input t
                        quit-flag nil)))
              (funcall check-conn))
             (t
              (while t
                (funcall check-conn)
                (accept-process-output nil 30))))
       (list #'identity cancel-on-input-retval))

Also, I think this happens when another request called by this function
has recently been canceled, i.e. the user typed something during the
sit-for, which is _not_ C-g, quickly followed by an invocation of this
same block, _coming from a "get docstring for completion"
(:company-docsig) timer fired by company-mode.  I think if I manage to
type C-g during around that time it crashes.

This intuition, is what lead me to stuff the code with inhibit-quit and
(setq quit-flag nil) and stuff like that.  Because I want to make sure
C-g doesn't get in there.  Perhaps it still does.  Perhaps it is
counter-productive to do this.

Thanks for your help,
João