GNU bug report logs - #35253
emacs-27.0.50_2019-01-17; `-nw' option causes core dump

Previous Next

Package: emacs;

Reported by: Atsuo Ohki <ohki1701g <at> gmail.com>

Date: Sat, 13 Apr 2019 02:52:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #8 received at 35253 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Atsuo Ohki <ohki1701g <at> gmail.com>
Cc: 35253 <at> debbugs.gnu.org
Subject: Re: bug#35253: emacs-27.0.50_2019-01-17; `-nw' option causes core dump
Date: Sat, 13 Apr 2019 09:41:11 +0300
> From: Atsuo Ohki <ohki1701g <at> gmail.com>
> Date: Sat, 13 Apr 2019 11:40:02 +0900
> Cc: ohki1701g <at> gmail.com
> 
> 
>  emacs-27.0.50_2019-01-17 built with following configuration dumps core
>  (segmentaion fault), when `-nw' option is specified.
> 
>  When built it with `--with-pdumper=no --with-dumping=unexec'
>  configuration options, it works fine with `-nw' option.
> 
>  I suspected the reinitialization after loading a pdmp file is
>  inadequate, and found the next patch fixes the problem.

Thanks.  Can you show the backtrace from the crash?

Also, does "_2019-01-17" above mean that this is a Jan 2019 snapshot
of the development sources?  Because I think this problem was already
reported and fixed since then, with this fragment at the end of
coding.c in the current sources:

  /* In temacs the below is done by mule-conf.el, because we need to
     define us-ascii first.  But in dumped Emacs us-ascii is restored
     by the above loop, and mule-conf.el will not be loaded, so we set
     it up now; otherwise safe_terminal_coding will remain zeroed.  */
  Fset_safe_terminal_coding_system_internal (Qus_ascii);




This bug report was last modified 6 years and 44 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.