all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Sergio Pokrovskij <sergio.pokrovskij@gmail.com>
To: bug-gnu-emacs@gnu.org
Subject: bug#4585: A flaky temacs dump failure
Date: Tue, 29 Sep 2009 19:14:47 +0700	[thread overview]
Message-ID: <42f485580909290514k462228e6m1c8b2283f06a1e4d@mail.gmail.com> (raw)

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






             reply	other threads:[~2009-09-29 12:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-29 12:14 Sergio Pokrovskij [this message]
2016-06-05 18:04 ` bug#4585: A flaky temacs dump failure Noam Postavsky

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=42f485580909290514k462228e6m1c8b2283f06a1e4d@mail.gmail.com \
    --to=sergio.pokrovskij@gmail.com \
    --cc=4585@emacsbugs.donarmstrong.com \
    --cc=bug-gnu-emacs@gnu.org \
    /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.