all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: "João Távora" <joaotavora@gmail.com>
Cc: 34394@debbugs.gnu.org
Subject: bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g
Date: Sat, 09 Feb 2019 09:59:57 +0200	[thread overview]
Message-ID: <83wom9o0hu.fsf@gnu.org> (raw)
In-Reply-To: <87va1tye42.fsf@gmail.com> (message from João Távora on Sat, 09 Feb 2019 00:55:41 +0000)

> 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?





  reply	other threads:[~2019-02-09  7:59 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-09  0:55 bug#34394: 27.0.50; Emacs segfaults with SLY, company and C-g João Távora
2019-02-09  7:59 ` Eli Zaretskii [this message]
2019-02-09  9:45   ` João Távora
2019-02-09 10:10     ` Eli Zaretskii
2019-02-09 11:31       ` João Távora
2019-02-09 12:11         ` Eli Zaretskii
2019-02-09 12:33           ` Eli Zaretskii
2019-02-09 12:56             ` João Távora
2019-02-09 13:11               ` Eli Zaretskii
2019-02-09 13:23                 ` João Távora
2019-02-09 13:46                   ` Eli Zaretskii
2019-02-09 14:00                     ` João Távora
2019-02-09 14:01                       ` João Távora
2019-02-09 14:13                         ` João Távora
2019-02-09 14:36                           ` Eli Zaretskii
2019-02-09 15:21                           ` Eli Zaretskii
2019-02-09 15:37                             ` João Távora
2019-02-09 15:51                               ` Eli Zaretskii
2019-02-09 16:04                                 ` João Távora
2019-02-09 16:14                                   ` João Távora
2019-02-09 16:20                                     ` Eli Zaretskii
2019-02-09 16:26                                       ` João Távora
2019-02-09 20:08                                         ` João Távora
2019-02-10 16:42                                           ` Eli Zaretskii
2019-02-12 17:25                                             ` Eli Zaretskii
2019-02-12 18:10                                               ` João Távora
2019-02-12 18:29                                                 ` Eli Zaretskii
2019-02-12 19:15                                                   ` Eli Zaretskii
2019-02-12 20:42                                                     ` João Távora
2019-02-13 16:26                                                       ` Eli Zaretskii
2019-02-18 20:42                                                         ` João Távora
2019-02-19  3:28                                                           ` Eli Zaretskii
2019-02-09 16:21                                   ` Eli Zaretskii
2019-02-09 14:48                       ` Eli Zaretskii
2019-02-09 11:38       ` João Távora
2019-02-09  8:08 ` Andreas Schwab

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83wom9o0hu.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=34394@debbugs.gnu.org \
    --cc=joaotavora@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.