bug#28279: 25.2; repeatable crash when hitting C-g twice

bug#28279: 25.2; repeatable crash when hitting C-g twice

[Eric Hoffman]

I dont think its necessary, bu after 30 years I've developed the muscle
memory of hitting C-g twiceif I want to get back to a known state.
I've noticed this happening on OSX using a brew-installed 25.4, but
recently after noticing it on Freebsd, I compiled from source with
deubugging turned on. It doesn't happen every time, but usually about
once every 30 minutes with my particular usage

  OS: FreeBSD 11.0-RELEASE-p9
  Compiler: FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564)
           (based on LLVM 3.8.0)
  Emacs: "25.2.1"
  Stacktrace:
  0x4af3e4 <emacs_backtrace+0x54> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x4938fc <terminate_due_to_signal+0x5c> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x4ad7a3 <emacs_abort+0x13> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x50c474 <Fsignal+0x4b4> at /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x512cf5 <Fassq+0x15> at /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x48cfbe <Fterminal_parameter+0x7e> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x48c1e7 <tty_send_additional_strings+0x17> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x48b7ef <tty_reset_terminal_modes+0x1f> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x4ae851 <reset_sys_modes+0x101> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x4ae738 <reset_all_sys_modes+0x18> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x49dce5 <handle_interrupt+0xb5> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x4aecd7 <deliver_process_signal+0x37> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
  0x80195378f <pthread_sigmask+0x4ff> at /lib/libthr.so.3
  0x801952d6f <pthread_getspecific+0xe9f> at /lib/libthr.so.3

If someone wants to track this down and wants more information, I can
try to run it in the debugger (i struggle some with lldb), or recompile
with instrumentation

as always, thanks for...emacs...I think the last time I filed a bug was
around 1990



In GNU Emacs 25.2.1 (x86_64-unknown-freebsd11.0)
 of 2017-08-23 built on zeitgeist.tenuki.org
Configured features:
SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  display-time-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  file-name-shadow-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit [2 times]

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date time image
shell pcomplete comint regexp-opt ansi-color ring mule-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select mouse jit-lock font-lock syntax
facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote kqueue multi-tty
make-network-process emacs)

Memory information:
((conses 16 87371 5095)
 (symbols 48 19375 0)
 (miscs 40 113 98)
 (strings 32 15961 5305)
 (string-bytes 1 467507)
 (vectors 16 10054)
 (vector-slots 8 385356 12608)
 (floats 8 155 132)
 (intervals 56 127 3)
 (buffers 976 24))

bug#28279: 25.2; repeatable crash when hitting C-g twice

[Eli Zaretskii]

> From: Eric Hoffman <yuri@tenuki.org>
> Date: Tue, 29 Aug 2017 18:20:10 +0000
> 
> 
> I dont think its necessary, bu after 30 years I've developed the muscle
> memory of hitting C-g twiceif I want to get back to a known state.
> I've noticed this happening on OSX using a brew-installed 25.4, but
> recently after noticing it on Freebsd, I compiled from source with
> deubugging turned on. It doesn't happen every time, but usually about
> once every 30 minutes with my particular usage

Can you tell what do you do, before the double C-g, to trigger this?
Does this happen if you start "emacs -Q" and the type C-0g twice, for
example?

Thanks.

bug#28279: 25.2; repeatable crash when hitting C-g twice

[Glenn Morris]

Eric Hoffman wrote:

>   0x4ad7a3 <emacs_abort+0x13> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
>   0x50c474 <Fsignal+0x4b4> at /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
>   0x512cf5 <Fassq+0x15> at /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
>   0x48cfbe <Fterminal_parameter+0x7e> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
>   0x48c1e7 <tty_send_additional_strings+0x17> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1

This appears to be https://debbugs.gnu.org/17406

bug#28279: 25.2; repeatable crash when hitting C-g twice

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 29 Aug 2017 15:38:44 -0400
> Cc: 28279@debbugs.gnu.org
> 
> Eric Hoffman wrote:
> 
> >   0x4ad7a3 <emacs_abort+0x13> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
> >   0x50c474 <Fsignal+0x4b4> at /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
> >   0x512cf5 <Fassq+0x15> at /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
> >   0x48cfbe <Fterminal_parameter+0x7e> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
> >   0x48c1e7 <tty_send_additional_strings+0x17> at  /usr/home/yuri/emacs-25.2/src/emacs-25.2.1
> 
> This appears to be https://debbugs.gnu.org/17406

Does the below look reasonable for a fix?

diff --git a/src/term.c b/src/term.c
index 87a4126..5042abf 100644
--- a/src/term.c
+++ b/src/term.c
@@ -156,13 +156,17 @@ static void
 tty_send_additional_strings (struct terminal *terminal, Lisp_Object sym)
 {
   Lisp_Object lisp_terminal;
-  Lisp_Object extra_codes;
   struct tty_display_info *tty = terminal->display_info.tty;
 
   XSETTERMINAL (lisp_terminal, terminal);
-  for (extra_codes = Fterminal_parameter (lisp_terminal, sym);
-       CONSP (extra_codes);
-       extra_codes = XCDR (extra_codes))
+  /* We use CDR_SAFE and assq_no_quit to avoid any form of quitting or
+     signaling an error, since this function can run as part of the
+     "emergency escape" procedure invoked in the middle of GC, where
+     quitting means we crash.  */
+  Lisp_Object extra_codes =
+    CDR_SAFE (assq_no_quit (sym,
+			    decode_live_terminal (lisp_terminal)->param_alist));
+  for ( ; CONSP (extra_codes); extra_codes = XCDR (extra_codes))
     {
       Lisp_Object string = XCAR (extra_codes);
       if (STRINGP (string))

bug#28279: 25.2; repeatable crash when hitting C-g twice

[Glenn Morris]

Eli Zaretskii wrote:

> Does the below look reasonable for a fix?

Sorry, I don't know. If you want a second opinion, ask Paul?

bug#28279: 25.2; repeatable crash when hitting C-g twice

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: yuri@tenuki.org,  28279@debbugs.gnu.org
> Date: Thu, 31 Aug 2017 12:48:26 -0400
> 
> Eli Zaretskii wrote:
> 
> > Does the below look reasonable for a fix?
> 
> Sorry, I don't know. If you want a second opinion, ask Paul?

I just wrote code that does the same as the original one, but calls
assq_no_quit instead of Fassq and CDR_SAFE instead of Fcdr.  This
should not signal an error nor QUIT, which was the root cause for the
abort.

bug#28279: 25.2; repeatable crash when hitting C-g twice

[Eric Hoffman]

  rgm@gnu.org: This appears to be https://debbugs.gnu.org/17406

it may be related, the only minor difference is that dont get presented
with the normal abort query, it just stops.

   Can you tell what do you do, before the double C-g, to trigger this?
   Does this happen if you start "emacs -Q" and the type C-0g twice, for
   example?

sorry, I should have said 'quasi repeatable', I cant get it to happen
on a new emacs. I suspect I do this when there is a delay in response and
this is my way of trying to determine if its the network or emacs. which
means that correlation with gc activity as in 17406 is probably high.I will
I can probably try to verify that by making lots of trash