GNU bug report logs - #4585
A flaky temacs dump failure

Previous Next

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

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

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Sergio Pokrovskij <sergio.pokrovskij <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: A flaky temacs dump failure
Date: Tue, 29 Sep 2009 19:14:47 +0700

There is a very infrequent failure at the temacs dump stage, which
seems to be due to a read from uninitialized memory.

The problem is common to several versions of emacs; in this report I
use v. 22.3; it is all the same in the cvs version.

Sometimes it leads to a Segmentation Fault.  This is a flaky
(unstable) behavior, but there are two ways to reproduce the symptom:

1. Compile with Intel's icc compiler using the -check-uninit option, or

2. Use valgrind (for either gcc or icc build -- the results are
   similar).

src/temacs produced by Intel's icc reports this:
,----
| LC_ALL=C ./temacs -batch -l loadup dump
|
| Run-Time Check Failure: The variable '__d1' is being used without
being initialized
|
| make[1]: *** [emacs] Aborted
`----

But I suppose you should prefer the GNU utilities.

Here is the Valgrind's output for the gcc build (it has completed
successfully and I am using the constructed src/emacs to prepare this
report and give the build details; but after the build I am repeating
the temacs dump with Valgrind):

% LC_ALL=C valgrind --quiet --trace-children=yes --tool=memcheck
./temacs -batch -l loadup dump
==29515== Invalid read of size 4
==29515==    at 0x80BA240: reset_buffer_local_variables (buffer.c:748)
==29515==    by 0x80C00FA: Fget_buffer_create (buffer.c:413)
==29515==    by 0x805F239: ensure_echo_area_buffers (xdisp.c:7956)
==29515==    by 0x805F2D2: with_echo_area_buffer (xdisp.c:7992)
==29515==    by 0x805F6AB: current_message (xdisp.c:8484)
==29515==    by 0x805F6DB: push_message (xdisp.c:8519)
==29515==    by 0x80F2FD5: Fgarbage_collect (alloc.c:5123)
==29515==    by 0x810769D: Ffuncall (eval.c:2927)
==29515==    by 0x8107B88: call2 (eval.c:2800)
==29515==    by 0x8107C47: Fsignal (eval.c:1652)
==29515==    by 0x8107E27: xsignal (eval.c:1725)
==29515==    by 0x810830F: xsignal1 (eval.c:1742)
==29515==  Address 0x618 is not stack'd, malloc'd or (recently) free'd
==29515==
==29515== Process terminating with default action of signal 11 (SIGSEGV)
==29515==  Access not within mapped region at address 0x618
==29515==    at 0x80BA240: reset_buffer_local_variables (buffer.c:748)
==29515==    by 0x80C00FA: Fget_buffer_create (buffer.c:413)
==29515==    by 0x805F239: ensure_echo_area_buffers (xdisp.c:7956)
==29515==    by 0x805F2D2: with_echo_area_buffer (xdisp.c:7992)
==29515==    by 0x805F6AB: current_message (xdisp.c:8484)
==29515==    by 0x805F6DB: push_message (xdisp.c:8519)
==29515==    by 0x80F2FD5: Fgarbage_collect (alloc.c:5123)
==29515==    by 0x810769D: Ffuncall (eval.c:2927)
==29515==    by 0x8107B88: call2 (eval.c:2800)
==29515==    by 0x8107C47: Fsignal (eval.c:1652)
==29515==    by 0x8107E27: xsignal (eval.c:1725)
==29515==    by 0x810830F: xsignal1 (eval.c:1742)
Segmentation fault
%
=============================================

In GNU Emacs 22.3.1 (i686-pc-linux-gnu)
 of 2009-09-29 on nsticlxlqa1
configured using `configure  '--without-x''

Important settings:
  value of $LC_ALL: en_US.iso885915
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  locale-coding-system: iso-8859-15
  default-enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  encoded-kbd-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
ESC x r e p o r t - e m a c s - b u g RET

Recent messages:
("./emacs" "-q")
Loading encoded-kb...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done


-- 
Sergio

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

From: Noam Postavsky <npostavs <at> users.sourceforge.net>
To: 4585 <at> debbugs.gnu.org
Cc: Sergio Pokrovskij <sergio.pokrovskij <at> gmail.com>
Subject: A flaky temacs dump failure
Date: Sun, 5 Jun 2016 14:04:51 -0400

tag 4585 + unreproducible
quit

I'm not able to reproduce this on Emacs 25 pretest with valgrind. Is it fixed?

In GNU Emacs 25.0.94.6 (x86_64-unknown-linux-gnu, X toolkit)
 of 2016-06-04 built on zony
Repository revision: 7eb3bd56d0f0410d5053ee01f4b458d868682df6
Windowing system distributor 'The X.Org Foundation', version 11.0.11803000
Configured using:
 'configure --cache-file=../debug-config.cache 'CFLAGS=-Og -g3
 -march=native' --enable-checking --with-x-toolkit=lucid
 --without-toolkit-scroll-bars --with-gif=no --with-jpeg=no'

Note that I have to --enable-checking so that USE_VALGRIND is #defined
in alloc.c otherwise valgrind complains a lot during GC.

I do get an error at the end of dumping, "a gap between BSS and heap".
I guess valgrind makes such a gap to aid in finding errors, so it's
not possible to successfully dump when running valgrind (not something
that needs to be fixed though).

~/src/emacs/emacs-25/src$ LC_ALL=C valgrind --quiet
--trace-children=yes --tool=memcheck ./temacs -batch -l loadup dump
Loading loadup.el (source)...
Using load-path (/home/npostavs/src/emacs/emacs-25/lisp)
Loading emacs-lisp/byte-run...
Loading emacs-lisp/backquote...
Loading subr...
Loading version...
Loading widget...
Loading custom...
Loading emacs-lisp/map-ynp...
Loading international/mule...
Loading international/mule-conf...
Loading env...
Loading format...
Loading bindings...
Loading window...
Loading files...
Loading emacs-lisp/macroexp...
Loading cus-face...
Loading faces...
Loading button...
Loading loaddefs.el (source)...
Loading emacs-lisp/nadvice...
Loading emacs-lisp/cl-preloaded...
Loading minibuffer...
Loading abbrev...
Loading simple...
Loading help...
Loading jka-cmpr-hook...
Loading epa-hook...
Loading international/mule-cmds...
Loading case-table...
Loading international/charprop.el (source)...
Loading international/characters...
Loading international/charscript...
Loading composite...
Loading language/chinese...
Loading language/cyrillic...
Loading language/indian...
Loading language/sinhala...
Loading language/english...
Loading language/ethiopic...
Loading language/european...
Loading language/czech...
Loading language/slovak...
Loading language/romanian...
Loading language/greek...
Loading language/hebrew...
Loading international/cp51932...
Loading international/eucjp-ms...
Loading language/japanese...
Loading language/korean...
Loading language/lao...
Loading language/tai-viet...
Loading language/thai...
Loading language/tibetan...
Loading language/vietnamese...
Loading language/misc-lang...
Loading language/utf-8-lang...
Loading language/georgian...
Loading language/khmer...
Loading language/burmese...
Loading language/cham...
Loading indent...
Loading emacs-lisp/cl-generic...
Loading frame...
Loading startup...
Loading term/tty-colors...
Loading font-core...
Loading facemenu...
Loading emacs-lisp/syntax...
Loading font-lock...
Loading jit-lock...
Loading mouse...
Loading scroll-bar...
Loading select...
Loading emacs-lisp/timer...
Loading isearch...
Loading rfn-eshadow...
Loading menu-bar...
Loading emacs-lisp/lisp...
Loading textmodes/page...
Loading register...
Loading textmodes/paragraphs...
Loading progmodes/prog-mode...
Loading emacs-lisp/lisp-mode...
Loading progmodes/elisp-mode...
Loading textmodes/text-mode...
Loading textmodes/fill...
Loading newcomment...
Loading replace...
Loading emacs-lisp/tabulated-list...
Loading buff-menu...
Loading fringe...
Loading emacs-lisp/regexp-opt...
Loading image...
Loading international/fontset...
Loading dnd...
Loading tool-bar...
Loading dynamic-setting...
Loading x-dnd...
Loading term/common-win...
Loading term/x-win...
Loading mwheel...
Loading emacs-lisp/float-sup...
Loading vc/vc-hooks...
Loading vc/ediff-hook...
Loading uniquify...
Loading electric...
Loading emacs-lisp/eldoc...
Loading cus-start...
Loading tooltip...
Loading leim/leim-list.el (source)...
Finding pointers to doc strings...
Finding pointers to doc strings...done
Pure-hashed: 24139 strings, 3794 vectors, 38658 conses, 3701
bytecodes, 102 others
Dumping under the name emacs
**************************************************
Warning: Your system has a gap between BSS and the
heap (55495551 bytes).  This usually means that exec-shield
or something similar is in effect.  The dump may
fail because of this.  See the section about
exec-shield in etc/PROBLEMS for more information.
**************************************************
**20737** Program aborting because of call to malloc_get_state
==20737==    at 0x4C2A96F: ??? (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20737==    by 0x4C2A996: ??? (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20737==    by 0x4C2AA06: malloc_get_state (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20737==    by 0x5CA1DD: alloc_unexec_pre (alloc.c:124)
==20737==    by 0x5488C4: Fdump_emacs (emacs.c:2090)
==20737==    by 0x5F08A1: eval_sub (eval.c:2169)
==20737==    by 0x5F0DFC: Fprogn (eval.c:426)
==20737==    by 0x5F04F1: eval_sub (eval.c:2119)
==20737==    by 0x5F3E61: Fif (eval.c:383)
==20737==    by 0x5F04F1: eval_sub (eval.c:2119)
==20737==    by 0x62BEF4: readevalloop (lread.c:1927)
==20737==    by 0x62C85C: Fload (lread.c:1335)

Previous Next

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