[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g
From: |
João Távora |
Subject: |
bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g |
Date: |
Sat, 09 Feb 2019 09:45:13 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
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
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, João Távora, 2019/02/08
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, Eli Zaretskii, 2019/02/09
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g,
João Távora <=
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, Eli Zaretskii, 2019/02/09
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, João Távora, 2019/02/09
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, Eli Zaretskii, 2019/02/09
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, Eli Zaretskii, 2019/02/09
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, João Távora, 2019/02/09
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, Eli Zaretskii, 2019/02/09
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, João Távora, 2019/02/09
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, Eli Zaretskii, 2019/02/09
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, João Távora, 2019/02/09
- bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g, João Távora, 2019/02/09