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.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 35253 in the body.
You can then email your comments to 35253 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#35253; Package emacs. (Sat, 13 Apr 2019 02:52:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Atsuo Ohki <ohki1701g <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 13 Apr 2019 02:52:02 GMT) Full text and rfc822 format available.

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

From: Atsuo Ohki <ohki1701g <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: ohki1701g <at> gmail.com
Subject: emacs-27.0.50_2019-01-17; `-nw' option causes core dump
Date: Sat, 13 Apr 2019 11:40:02 +0900
 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.


--- src/coding.c-ORIG   2019-01-17 19:31:05.000000000 +0900
+++ src/coding.c        2019-04-13 10:53:04.819899000 +0900
@@ -11341,4 +11341,5 @@
           setup_coding_system (CODING_ID_NAME (id), this);
         }
     }
+  setup_coding_system (Qno_conversion, &safe_terminal_coding);
 }


#------------------------------------------------------------------------
In GNU Emacs 27.0.50 (build 1, x86_64-pc-freebsd11, X toolkit, Xaw3d scroll bars)
 of 2019-04-13 built on hz550
System Description: 11.2-STABLE

Recent messages:
Loading /usr/local/share/emacs/site-lisp/site-start-27.x.el (source)...done
Waiting for git... [2 times]
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure amd64-freebsd11
 --srcdir=/usr/src/local/GNU/emacs/emacs-27.0.50 --with-x
 --x-includes=/usr/local/include --x-libraries=/usr/local/lib
 --with-x-toolkit=lucid --without-xim --with-modules --without-pop
 --without-xpm --without-jpeg --without-tiff --without-gif --without-png
 --without-rsvg --without-imagemagick --without-gpm --without-dbus
 --without-gconf --without-gsettings --without-selinux --without-sound
 --without-gnutls LDFLAGS=-L/usr/local/lib'

Configured features:
XAW3D NOTIFY KQUEUE ACL LIBXML2 FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS
LUCID X11 XDBE XIM MODULES THREADS CANNOT_DUMP LCMS2 GMP

Important settings:
  locale-coding-system: nil

Major mode: Lisp Interaction

Minor modes in effect:
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils elec-pair tramp tramp-loaddefs
trampver tramp-compat ucs-normalize shell pcomplete comint ansi-color
ring parse-time format-spec advice auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json map seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib japan-util ps-print
ps-print-loaddefs ps-def lpr disp-table mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors 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 composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray 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 threads kqueue lcms2 dynamic-setting font-render-setting
x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 178146 7158)
 (symbols 48 8084 1)
 (strings 32 23697 2126)
 (string-bytes 1 790174)
 (vectors 16 31725)
 (vector-slots 8 421034 10170)
 (floats 8 275 289)
 (intervals 56 140 0)
 (buffers 992 11))




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#35253; Package emacs. (Sat, 13 Apr 2019 06:42:01 GMT) Full text and rfc822 format available.

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);




Reply sent to Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility. (Sat, 13 Apr 2019 09:32:02 GMT) Full text and rfc822 format available.

Notification sent to Atsuo Ohki <ohki1701g <at> gmail.com>:
bug acknowledged by developer. (Sat, 13 Apr 2019 09:32:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Atsuo Ohki <ohki1701g <at> gmail.com>
Cc: 35253-done <at> debbugs.gnu.org, ohki1701g <at> gmail.com
Subject: Re: bug#35253: emacs-27.0.50_2019-01-17; `-nw' option causes core dump
Date: Sat, 13 Apr 2019 12:31:14 +0300
> From: Atsuo Ohki <ohki1701g <at> gmail.com>
> Cc: Atsuo Ohki <ohki1701g <at> gmail.com>
> Comments: In-reply-to Eli Zaretskii <eliz <at> gnu.org>
>    message dated "Sat, 13 Apr 2019 09:41:11 +0300."
> Date: Sat, 13 Apr 2019 17:32:10 +0900
> 
> > 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);
> 
>  Thank you for an action.
> 
>  As you guess, I used a Jan 2019 snapshot of the development sources
>  got from http://alpha.gnu.org/gnu/emacs/pretest.
> 
>  A segmentation fault occurs in the function `encode_coding()',
>  when refering `coding->encoder' (`coding' is null at that point).
> 
>  So, I'm sure my bug report has already fixed.

Thanks, I'm therefore closing this bug report.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 11 May 2019 11:24:05 GMT) Full text and rfc822 format available.

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.