GNU bug report logs - #8705
Emacs 24.3 occasionally crashes (segfault) just after starting it

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 8705 in the body.
You can then email your comments to 8705 AT debbugs.gnu.org in the normal way.

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

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: bug-gnu-emacs <at> gnu.org
Cc: vincent <at> vinc17.net
Subject: 23.3; Emacs occasionally crashes (segfault) just after starting it
Date: Fri, 20 May 2011 10:54:28 +0200

Emacs23 occasionally crashes (segmentation fault) just after starting
it. Here this was the first time with Emacs 23.3 (Debian's package).

All crashes of Emacs 22 and 23 I got occurred immediately after
starting it, and most of them (if not all) occurred either on an
XML file or when Emacs was started via svn to write a log message.

Here's a backtrace:

(gdb) bt
#0  0x00007fa7df0056b7 in kill () at ../sysdeps/unix/syscall-template.S:82
#1  0x00000000004e4a5f in ?? ()
#2  <signal handler called>
#3  getenv (name=0x7fa7df118177 "NGUAGE") at getenv.c:84
#4  0x00007fa7df00034e in guess_category_value (
    domainname=0x7fa7e4afea1a "gtk20-properties", 
    msgid1=<value optimized out>, msgid2=<value optimized out>, 
    plural=<value optimized out>, n=<value optimized out>, 
    category=<value optimized out>) at dcigettext.c:1359
#5  __dcigettext (domainname=0x7fa7e4afea1a "gtk20-properties", 
    msgid1=<value optimized out>, msgid2=<value optimized out>, 
    plural=<value optimized out>, n=<value optimized out>, 
    category=<value optimized out>) at dcigettext.c:575
#6  0x00007fa7e48a7a3a in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#7  0x00007fa7e2b429e5 in g_type_class_ref () from /usr/lib/libgobject-2.0.so.0
#8  0x00007fa7e2b2659e in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#9  0x00007fa7e2b26e1c in g_object_new () from /usr/lib/libgobject-2.0.so.0
#10 0x00007fa7e48a82bc in gtk_alignment_new ()
   from /usr/lib/libgtk-x11-2.0.so.0
#11 0x00007fa7e4a3e88e in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#12 0x00007fa7e2b45443 in g_type_create_instance ()
   from /usr/lib/libgobject-2.0.so.0
#13 0x00007fa7e2b22dfc in ?? () from /usr/lib/libgobject-2.0.so.0
#14 0x00007fa7e2b26121 in g_object_newv () from /usr/lib/libgobject-2.0.so.0
#15 0x00007fa7e2b26e1c in g_object_new () from /usr/lib/libgobject-2.0.so.0
#16 0x00007fa7e4a400a1 in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#17 0x00007fa7e49642f8 in gtk_main_do_event ()
   from /usr/lib/libgtk-x11-2.0.so.0
#18 0x00007fa7e45cdb7c in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#19 0x00007fa7e22564a3 in g_main_context_dispatch ()
   from /lib64/libglib-2.0.so.0
#20 0x00007fa7e2256c80 in ?? () from /lib64/libglib-2.0.so.0
#21 0x00007fa7e2256f1d in g_main_context_iteration ()
   from /lib64/libglib-2.0.so.0
#22 0x00007fa7e49634c1 in gtk_main_iteration ()
   from /usr/lib/libgtk-x11-2.0.so.0
#23 0x00000000004aa33c in ?? ()
#24 0x00000000004ef993 in ?? ()
[...]

For more information, see my Debian bug reports:
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594592 (Emacs 23)
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511003 (Emacs 22)


In GNU Emacs 23.3.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.4)
 of 2011-04-10 on brahms, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11001000
configured using `configure  '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu' '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--localstatedir=/var/lib' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--with-pop=yes' '--enable-locallisppath=/etc/emacs23:/etc/emacs:/usr/local/share/emacs/23.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/23.3/site-lisp:/usr/share/emacs/site-lisp:/usr/share/emacs/23.3/leim' '--with-x=yes' '--with-x-toolkit=gtk' '--with-toolkit-scroll-bars' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-DDEBIAN -g -O2' 'LDFLAGS=-g' 'CPPFLAGS=''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: POSIX
  value of $LC_CTYPE: en_US.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: en_DK
  value of $LANG: POSIX
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  display-time-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<escape> x r e p o r t - e m <tab> <return>

Recent messages:
Loading cjk-enc...done
Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...done
Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...done
Loading /etc/emacs/site-start.d/50psvn.el (source)...done
Loading /etc/emacs/site-start.d/50rnc-mode.el (source)...done
Loading /etc/emacs/site-start.d/50thailatex.el (source)...done
Loading /etc/emacs/site-start.d/50w3m-el.el (source)...done
Loading /home/vlefevre/share/emacs/site-lisp/mutteditor.el (source)...done
Loading time...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
/usr/share/emacs23/site-lisp/css-mode/css-mode hides /usr/share/emacs/site-lisp/css-mode/css-mode
/usr/share/emacs23/site-lisp/html-helper-mode/tempo hides /usr/share/emacs/site-lisp/html-helper-mode/tempo
/usr/share/emacs23/site-lisp/html-helper-mode/visual-basic-mode hides /usr/share/emacs/site-lisp/html-helper-mode/visual-basic-mode
/usr/share/emacs23/site-lisp/html-helper-mode/hhm-config hides /usr/share/emacs/site-lisp/html-helper-mode/hhm-config
/usr/share/emacs23/site-lisp/html-helper-mode/html-helper-mode hides /usr/share/emacs/site-lisp/html-helper-mode/html-helper-mode
/usr/share/emacs/23.3/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup
/usr/share/emacs/23.3/site-lisp/cmake-data/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode
/usr/share/emacs23/site-lisp/flim/sha1 hides /usr/share/emacs/23.3/lisp/sha1
/usr/share/emacs23/site-lisp/flim/hex-util hides /usr/share/emacs/23.3/lisp/hex-util
/usr/share/emacs23/site-lisp/flim/md4 hides /usr/share/emacs/23.3/lisp/md4
/usr/share/emacs23/site-lisp/html-helper-mode/tempo hides /usr/share/emacs/23.3/lisp/tempo
/usr/share/emacs23/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/23.3/lisp/textmodes/ispell
/usr/share/emacs23/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/23.3/lisp/textmodes/flyspell
/usr/share/emacs23/site-lisp/css-mode/css-mode hides /usr/share/emacs/23.3/lisp/textmodes/css-mode
/usr/share/emacs23/site-lisp/flim/hmac-md5 hides /usr/share/emacs/23.3/lisp/net/hmac-md5
/usr/share/emacs23/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/23.3/lisp/net/sasl-ntlm
/usr/share/emacs23/site-lisp/flim/ntlm hides /usr/share/emacs/23.3/lisp/net/ntlm
/usr/share/emacs23/site-lisp/flim/sasl hides /usr/share/emacs/23.3/lisp/net/sasl
/usr/share/emacs23/site-lisp/flim/sasl-cram hides /usr/share/emacs/23.3/lisp/net/sasl-cram
/usr/share/emacs23/site-lisp/flim/sasl-digest hides /usr/share/emacs/23.3/lisp/net/sasl-digest
/usr/share/emacs23/site-lisp/flim/hmac-def hides /usr/share/emacs/23.3/lisp/net/hmac-def
/usr/share/emacs23/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/23.3/lisp/language/thai-word

Features:
(shadow sort mail-extr message sendmail ecomplete rfc822 mml easymenu
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock
sha1 sha1-el hex-util hashcash mail-utils warnings emacsbug time
cus-start cus-load paren cc-styles cc-align cc-engine cc-vars cc-defs
regexp-opt w3m-load tooltip ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd font-setting tool-bar dnd fontset image fringe lisp-mode
register page menu-bar rfn-eshadow timer select scroll-bar mldrag mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
loaddefs button minibuffer faces cus-face files text-properties overlay
md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
system-font-setting font-render-setting gtk x-toolkit x multi-tty emacs)

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: 8705 <at> debbugs.gnu.org
Subject: Re: 23.3; Emacs occasionally crashes (segfault) just after starting it
Date: Fri, 20 May 2011 11:12:16 +0200

In case this matters, I use fvwm with ActivePlacement.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: 23.3;
	Emacs occasionally crashes (segfault) just after starting it
Date: Fri, 20 May 2011 13:40:34 +0300

> From: Vincent Lefevre <vincent <at> vinc17.net>
> Date: Fri, 20 May 2011 10:54:28 +0200
> Cc: vincent <at> vinc17.net
> 
> Emacs23 occasionally crashes (segmentation fault) just after starting
> it. Here this was the first time with Emacs 23.3 (Debian's package).
> 
> All crashes of Emacs 22 and 23 I got occurred immediately after
> starting it, and most of them (if not all) occurred either on an
> XML file or when Emacs was started via svn to write a log message.
> 
> Here's a backtrace:
> 
> (gdb) bt
> #0  0x00007fa7df0056b7 in kill () at ../sysdeps/unix/syscall-template.S:82
> #1  0x00000000004e4a5f in ?? ()
> #2  <signal handler called>
> #3  getenv (name=0x7fa7df118177 "NGUAGE") at getenv.c:84
> #4  0x00007fa7df00034e in guess_category_value (
>     domainname=0x7fa7e4afea1a "gtk20-properties", 
>     msgid1=<value optimized out>, msgid2=<value optimized out>, 
>     plural=<value optimized out>, n=<value optimized out>, 
>     category=<value optimized out>) at dcigettext.c:1359
> #5  __dcigettext (domainname=0x7fa7e4afea1a "gtk20-properties", 
>     msgid1=<value optimized out>, msgid2=<value optimized out>, 
>     plural=<value optimized out>, n=<value optimized out>, 
>     category=<value optimized out>) at dcigettext.c:575
> #6  0x00007fa7e48a7a3a in ?? () from /usr/lib/libgtk-x11-2.0.so.0
> #7  0x00007fa7e2b429e5 in g_type_class_ref () from /usr/lib/libgobject-2.0.so.0
> #8  0x00007fa7e2b2659e in g_object_newv () from /usr/lib/libgobject-2.0.so.0
> #9  0x00007fa7e2b26e1c in g_object_new () from /usr/lib/libgobject-2.0.so.0
> #10 0x00007fa7e48a82bc in gtk_alignment_new ()
>    from /usr/lib/libgtk-x11-2.0.so.0

All of your reported crashes seem to be in a call to `getenv', which
is a library function, called by GTK routines deep in the GTK code.
It is hard to imagine that they could be Emacs problems, especially
since you see them since Emacs 22.

In any case, backtraces from optimized programs are unreliable.
Please try rebuilding Emacs with -O0 in CFLAGS, and if you can
reproduce these crashes in the unoptimized build, follow up here with
the backtrace.

> #22 0x00007fa7e49634c1 in gtk_main_iteration ()
>    from /usr/lib/libgtk-x11-2.0.so.0
> #23 0x00000000004aa33c in ?? ()
> #24 0x00000000004ef993 in ?? ()
> [...]

Could you please show the backtrace until it reaches Emacs code?

Thanks.

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: 23.3;	Emacs occasionally crashes (segfault) just
	after starting it
Date: Fri, 20 May 2011 13:16:01 +0200

On 2011-05-20 13:40:34 +0300, Eli Zaretskii wrote:
> All of your reported crashes seem to be in a call to `getenv', which
> is a library function, called by GTK routines deep in the GTK code.
> It is hard to imagine that they could be Emacs problems, especially
> since you see them since Emacs 22.

Unless Emacs has corrupted the memory earlier. Unfortunately,
one cannot use valgrind on Emacs.

> In any case, backtraces from optimized programs are unreliable.
> Please try rebuilding Emacs with -O0 in CFLAGS, and if you can
> reproduce these crashes in the unoptimized build, follow up here with
> the backtrace.

I've rebuilt Emacs with -ggdb -O0. I now need to wait for another
crash, hoping that the -O0 won't make the bug disappear.

> > #22 0x00007fa7e49634c1 in gtk_main_iteration ()
> >    from /usr/lib/libgtk-x11-2.0.so.0
> > #23 0x00000000004aa33c in ?? ()
> > #24 0x00000000004ef993 in ?? ()
> > [...]
> 
> Could you please show the backtrace until it reaches Emacs code?

It was meaningless: I got nothing until __libc_start_main.
With the rebuild (I also installed the -dbg versions of the
libraries, when available in Debian), I should have more
information for the next crash...

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: 23.3;
	Emacs occasionally crashes (segfault) just after starting it
Date: Fri, 20 May 2011 14:38:58 +0300

> Date: Fri, 20 May 2011 13:16:01 +0200
> From: Vincent Lefevre <vincent <at> vinc17.net>
> Cc: 8705 <at> debbugs.gnu.org
> 
> On 2011-05-20 13:40:34 +0300, Eli Zaretskii wrote:
> > All of your reported crashes seem to be in a call to `getenv', which
> > is a library function, called by GTK routines deep in the GTK code.
> > It is hard to imagine that they could be Emacs problems, especially
> > since you see them since Emacs 22.
> 
> Unless Emacs has corrupted the memory earlier.

That's definitely a possibility.  However, it is strange that only you
see these problems for several versions.  If Emacs corrupts memory so
early into the session, many other users would be affected.

> I've rebuilt Emacs with -ggdb -O0. I now need to wait for another
> crash, hoping that the -O0 won't make the bug disappear.

Thanks.

> > Could you please show the backtrace until it reaches Emacs code?
> 
> It was meaningless: I got nothing until __libc_start_main.
> With the rebuild (I also installed the -dbg versions of the
> libraries, when available in Debian), I should have more
> information for the next crash...

Thanks again.

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: 23.3;	Emacs occasionally crashes (segfault) just
	after starting it
Date: Fri, 20 May 2011 14:59:19 +0200

On 2011-05-20 14:38:58 +0300, Eli Zaretskii wrote:
> > Date: Fri, 20 May 2011 13:16:01 +0200
> > From: Vincent Lefevre <vincent <at> vinc17.net>
> > Cc: 8705 <at> debbugs.gnu.org
> > 
> > On 2011-05-20 13:40:34 +0300, Eli Zaretskii wrote:
> > > All of your reported crashes seem to be in a call to `getenv', which
> > > is a library function, called by GTK routines deep in the GTK code.
> > > It is hard to imagine that they could be Emacs problems, especially
> > > since you see them since Emacs 22.
> > 
> > Unless Emacs has corrupted the memory earlier.
> 
> That's definitely a possibility.  However, it is strange that only you
> see these problems for several versions.  If Emacs corrupts memory so
> early into the session, many other users would be affected.

No, because other users have a different configuration. I'm quite
sure that the configuration matters as I got such crashes on
different machines (where I use the same config).

By configuration, I mean the .emacs, but also the graphical
environment (e.g. the window manager, fvwm in my case, and its
configuration). That wouldn't be the first time an application
is affected by the window manager. See

  https://bugzilla.mozilla.org/show_bug.cgi?id=551678

for instance, where I could reproduce a bug only with manual/active
placement.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: 23.3;	Emacs occasionally crashes (segfault) just
	after starting it
Date: Tue, 20 Sep 2011 16:51:37 +0200

[Message part 1 (text/plain, inline)]

On 2011-05-20 13:16:01 +0200, Vincent Lefevre wrote:
> I've rebuilt Emacs with -ggdb -O0. I now need to wait for another
> crash, hoping that the -O0 won't make the bug disappear.

This rebuilt GNU Emacs 23.3.1 crashed for the first time.

Core was generated by `emacs mpfrtests.data'.
Program terminated with signal 11, Segmentation fault.

I've attached the full backtrace.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

[gdb.txt (text/plain, attachment)]

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: 23.3;	Emacs occasionally crashes (segfault) just
	after starting it
Date: Fri, 6 Jul 2012 13:13:17 +0200

Any news?

This problem also occurs with GNU Emacs 24.1.1.

Core was generated by `emacs 55_lshift_type.expect'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007fc23c70c757 in kill () at ../sysdeps/unix/syscall-template.S:82
82      ../sysdeps/unix/syscall-template.S: No such file or directory.
(gdb) bt
#0  0x00007fc23c70c757 in kill () at ../sysdeps/unix/syscall-template.S:82
#1  0x0000000000500c9c in fatal_error_signal (sig=<optimized out>)
    at emacs.c:366
#2  fatal_error_signal (sig=<optimized out>) at emacs.c:336
#3  <signal handler called>
#4  *__GI_getenv (name=0x7fc23f04ccca "KB_CHARSET") at getenv.c:84
#5  0x00007fc23efc27ed in _XkbGetCharset ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007fc23efc0eed in XkbTranslateKeySym ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007fc23efc114a in XLookupString ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8  0x00007fc23ef9a81f in _XimLocalFilter ()
   from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9  0x00000000004c8de1 in x_filter_event (event=0x7fffba71b390, 
    dpyinfo=0xdc1000) at xterm.c:5793
#10 event_handler_gdk (gxev=0x7fffba71b390, ev=<optimized out>, 
    data=<optimized out>) at xterm.c:5823
#11 0x00007fc24218d3ca in gdk_event_apply_filters (filters=<optimized out>, 
    event=<optimized out>, xevent=<optimized out>)
    at /tmp/buildd/gtk+2.0-2.24.10/gdk/x11/gdkevents-x11.c:356
#12 gdk_event_translate (display=0xd93020, event=0x1c8c1d0, 
    xevent=0x7fffba71b390, return_exposes=0)
    at /tmp/buildd/gtk+2.0-2.24.10/gdk/x11/gdkevents-x11.c:927
#13 0x00007fc24218f136 in _gdk_events_queue (display=0xd93020)
    at /tmp/buildd/gtk+2.0-2.24.10/gdk/x11/gdkevents-x11.c:2310
#14 0x00007fc24218f1be in gdk_event_dispatch (source=<optimized out>, 
    source <at> entry=0xe35dc0, callback=<optimized out>, user_data=<optimized out>)
    at /tmp/buildd/gtk+2.0-2.24.10/gdk/x11/gdkevents-x11.c:2371
#15 0x00007fc240651205 in g_main_dispatch (context=0xe35e70)
    at /tmp/buildd/glib2.0-2.32.3/./glib/gmain.c:2539
#16 g_main_context_dispatch (context=context <at> entry=0xe35e70)
    at /tmp/buildd/glib2.0-2.32.3/./glib/gmain.c:3075
#17 0x00007fc240651538 in g_main_context_iterate (
    context=context <at> entry=0xe35e70, block=block <at> entry=1, 
    dispatch=dispatch <at> entry=1, 
    self=<error reading variable: Unhandled dwarf expression opcode 0xfa>)
    at /tmp/buildd/glib2.0-2.32.3/./glib/gmain.c:3146
#18 0x00007fc2406515f4 in g_main_context_iteration (context=0xe35e70, 
    may_block=1) at /tmp/buildd/glib2.0-2.32.3/./glib/gmain.c:3207
#19 0x00007fc242522c81 in IA__gtk_main_iteration ()
    at /tmp/buildd/gtk+2.0-2.24.10/gtk/gtkmain.c:1344
#20 0x00000000004bf72b in XTread_socket (terminal=<optimized out>, 
    expected=<optimized out>, hold_quit=0x7fffba71b6c0) at xterm.c:7187
#21 0x0000000000508d18 in read_avail_input (expected=expected <at> entry=1)
    at keyboard.c:6859
#22 0x0000000000508e2a in handle_async_input () at keyboard.c:7187
#23 0x000000000050a465 in reinvoke_input_signal () at keyboard.c:7243
#24 0x00000000005bfac5 in Fcall_process (nargs=10, args=0x7fffba72c3e8)
    at callproc.c:652
#25 0x00000000005783da in Ffuncall (nargs=nargs <at> entry=11, 
    args=args <at> entry=0x7fffba72c3e0) at eval.c:2984
#26 0x0000000000579207 in Fapply (nargs=<optimized out>, args=0x7fffba72c548)
    at eval.c:2507
#27 0x00000000005783da in Ffuncall (nargs=<optimized out>, 
    args=args <at> entry=0x7fffba72c540) at eval.c:2984
#28 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:785
#29 0x0000000000577e81 in funcall_lambda (fun=9571133, nargs=nargs <at> entry=10, 
    arg_vector=arg_vector <at> entry=0x7fffba72c738) at eval.c:3233
#30 0x00000000005781cb in Ffuncall (nargs=nargs <at> entry=11, 
    args=args <at> entry=0x7fffba72c730) at eval.c:3063
#31 0x0000000000579207 in Fapply (nargs=<optimized out>, args=0x7fffba72c898)
    at eval.c:2507
#32 0x00000000005783da in Ffuncall (nargs=<optimized out>, 
    args=args <at> entry=0x7fffba72c890) at eval.c:2984
#33 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:785
#34 0x0000000000577e81 in funcall_lambda (fun=31679093, nargs=nargs <at> entry=7, 
    arg_vector=arg_vector <at> entry=0x7fffba72ca78) at eval.c:3233
#35 0x00000000005781cb in Ffuncall (nargs=nargs <at> entry=8, 
    args=args <at> entry=0x7fffba72ca70) at eval.c:3063
#36 0x0000000000579207 in Fapply (nargs=<optimized out>, args=0x7fffba72cbc0)
    at eval.c:2507
#37 0x00000000005783da in Ffuncall (nargs=<optimized out>, 
    args=args <at> entry=0x7fffba72cbb8) at eval.c:2984
#38 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:785
#39 0x0000000000577e81 in funcall_lambda (fun=31007125, nargs=nargs <at> entry=6, 
    arg_vector=arg_vector <at> entry=0x7fffba72cd88) at eval.c:3233
#40 0x00000000005781cb in Ffuncall (nargs=7, args=args <at> entry=0x7fffba72cd80)
    at eval.c:3063
#41 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:785
#42 0x00000000005777d4 in eval_sub (form=form <at> entry=31437750) at eval.c:2356
#43 0x000000000057a9d1 in internal_lisp_condition_case (var=12010018, 
    bodyform=31437750, handlers=31437574) at eval.c:1469
#44 0x00000000005b09b6 in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:981
#45 0x0000000000577e81 in funcall_lambda (fun=31719157, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> entry=0x7fffba72d380) at eval.c:3233
#46 0x00000000005781cb in Ffuncall (nargs=nargs <at> entry=2, 
    args=args <at> entry=0x7fffba72d378) at eval.c:3063
#47 0x00000000005793aa in Fapply (nargs=2, args=0x7fffba72d378) at eval.c:2454
#48 0x00000000005783da in Ffuncall (nargs=<optimized out>, 
    args=args <at> entry=0x7fffba72d370) at eval.c:2984
#49 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:785
#50 0x0000000000577e81 in funcall_lambda (fun=10325781, nargs=nargs <at> entry=3, 
    arg_vector=arg_vector <at> entry=0x7fffba72d558) at eval.c:3233
#51 0x00000000005781cb in Ffuncall (nargs=4, args=args <at> entry=0x7fffba72d550)
    at eval.c:3063
#52 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:785
#53 0x0000000000577e81 in funcall_lambda (fun=10327125, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> entry=0x7fffba72d718) at eval.c:3233
#54 0x00000000005781cb in Ffuncall (nargs=nargs <at> entry=2, 
    args=args <at> entry=0x7fffba72d710) at eval.c:3063
#55 0x00000000005785ea in call1 (fn=fn <at> entry=10327125, arg1=<optimized out>)
    at eval.c:2771
#56 0x000000000057eefd in mapcar1 (leni=9, vals=vals <at> entry=0x0, 
    fn=fn <at> entry=10327125, seq=seq <at> entry=14761750) at fns.c:2346
#57 0x00000000005829d7 in Fmapc (function=10327125, sequence=14761750)
    at fns.c:2434
#58 0x0000000000578363 in Ffuncall (nargs=<optimized out>, 
    args=args <at> entry=0x7fffba72d830) at eval.c:3005
#59 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=<optimized out>, args=<optimized out>)
    at bytecode.c:785
#60 0x00000000005777d4 in eval_sub (form=form <at> entry=10327494) at eval.c:2356
#61 0x000000000057647b in internal_catch (tag=-2433983737013667, 
    func=0x5772e0 <eval_sub>, arg=10327494) at eval.c:1272
#62 0x00000000005b09f5 in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:966
#63 0x0000000000577e81 in funcall_lambda (fun=10327293, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> entry=0x7fffba72dcd8) at eval.c:3233
#64 0x00000000005781cb in Ffuncall (nargs=2, args=args <at> entry=0x7fffba72dcd0)
    at eval.c:3063
#65 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:785
#66 0x0000000000577e81 in funcall_lambda (fun=10327701, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> entry=0x7fffba72de98) at eval.c:3233
#67 0x00000000005781cb in Ffuncall (nargs=2, args=args <at> entry=0x7fffba72de90)
    at eval.c:3063
#68 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:785
#69 0x0000000000577e81 in funcall_lambda (fun=10336621, nargs=nargs <at> entry=0, 
    arg_vector=arg_vector <at> entry=0x7fffba72e0c8) at eval.c:3233
#70 0x00000000005781cb in Ffuncall (nargs=1, args=0x7fffba72e0c0)
    at eval.c:3063
#71 0x0000000000578689 in funcall_nil (nargs=<optimized out>, 
    args=<optimized out>) at eval.c:2519
#72 0x0000000000576bcd in run_hook_with_args (nargs=1, args=0x7fffba72e0c0, 
    funcall=0x578680 <funcall_nil>) at eval.c:2708
#73 0x0000000000576da6 in Frun_hooks (nargs=1, args=0x7fffba72e188)
    at eval.c:2546
#74 0x00000000005783da in Ffuncall (nargs=<optimized out>, 
    args=args <at> entry=0x7fffba72e180) at eval.c:2984
#75 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:785
#76 0x0000000000577e81 in funcall_lambda (fun=9054909, nargs=nargs <at> entry=2, 
    arg_vector=arg_vector <at> entry=0x7fffba72e358) at eval.c:3233
#77 0x00000000005781cb in Ffuncall (nargs=3, args=args <at> entry=0x7fffba72e350)
    at eval.c:3063
#78 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:785
#79 0x0000000000577e81 in funcall_lambda (fun=9051629, nargs=nargs <at> entry=6, 
    arg_vector=arg_vector <at> entry=0x7fffba72e518) at eval.c:3233
#80 0x00000000005781cb in Ffuncall (nargs=7, args=args <at> entry=0x7fffba72e510)
    at eval.c:3063
#81 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:785
#82 0x0000000000577e81 in funcall_lambda (fun=9049989, nargs=nargs <at> entry=4, 
    arg_vector=arg_vector <at> entry=0x7fffba72e6f8) at eval.c:3233
#83 0x00000000005781cb in Ffuncall (nargs=5, args=args <at> entry=0x7fffba72e6f0)
    at eval.c:3063
#84 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0x0) at bytecode.c:785
#85 0x0000000000577e81 in funcall_lambda (fun=9042469, nargs=nargs <at> entry=1, 
    arg_vector=arg_vector <at> entry=0x7fffba72e950) at eval.c:3233
#86 0x00000000005781cb in Ffuncall (nargs=2, args=args <at> entry=0x7fffba72e948)
    at eval.c:3063
#87 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=1, args=<optimized out>, 
    args <at> entry=0xaabd54) at bytecode.c:785
#88 0x0000000000577d79 in funcall_lambda (fun=9236685, nargs=nargs <at> entry=1, 
    arg_vector=0xaabd54, arg_vector <at> entry=0x7fffba72eaa8) at eval.c:3167
#89 0x00000000005781cb in Ffuncall (nargs=2, args=args <at> entry=0x7fffba72eaa0)
    at eval.c:3063
#90 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0xaae1a0) at bytecode.c:785
#91 0x0000000000577d79 in funcall_lambda (fun=9212341, nargs=nargs <at> entry=0, 
    arg_vector=0xaae1a0, arg_vector <at> entry=0x7fffba72ec70) at eval.c:3167
#92 0x00000000005781cb in Ffuncall (nargs=1, args=args <at> entry=0x7fffba72ec68)
    at eval.c:3063
#93 0x00000000005b007b in exec_byte_code (bytestr=<optimized out>, 
    vector=<optimized out>, maxdepth=<optimized out>, 
    args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0xaaf0e6) at bytecode.c:785
#94 0x0000000000577d79 in funcall_lambda (fun=9206885, fun <at> entry=9206797, 
    nargs=nargs <at> entry=0, arg_vector=0xaaf0e6, arg_vector <at> entry=0x7fffba72ed40)
    at eval.c:3167
#95 0x0000000000577214 in apply_lambda (fun=9206797, args=<optimized out>)
    at eval.c:3110
#96 0x00000000005775db in eval_sub (form=form <at> entry=12419398) at eval.c:2414
#97 0x000000000057a2d8 in Feval (form=12419398, lexical=<optimized out>)
    at eval.c:2204
#98 0x0000000000576581 in internal_condition_case (
    bfun=bfun <at> entry=0x5040e0 <top_level_2>, handlers=12062306, 
    hfun=hfun <at> entry=0x505920 <cmd_error>) at eval.c:1515
#99 0x0000000000504616 in top_level_1 (ignore=ignore <at> entry=12010018)
    at keyboard.c:1177
#100 0x000000000057647b in internal_catch (tag=-2433983737013667, 
    func=func <at> entry=0x5045b0 <top_level_1>, arg=12010018) at eval.c:1272
#101 0x00000000005053d7 in command_loop () at keyboard.c:1132
#102 recursive_edit_1 () at keyboard.c:759
#103 0x000000000050571d in Frecursive_edit () at keyboard.c:823
#104 0x0000000000416e6d in main (argc=2, argv=<optimized out>) at emacs.c:1715

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

From: Troels Nielsen <bn.troels <at> gmail.com>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: 23.3; Emacs occasionally crashes (segfault) just after
	starting it
Date: Fri, 6 Jul 2012 22:32:46 +0200

It appears this is due to Fcall_process not restoring environ before
after UNBLOCK_INPUT. This is too late in your case.

The patch below against trunk, ought to fix it with minimal
intervention. But I think a better fix would be to abandon the use of
vfork and just use fork (which should be almost as fast), as the work
in the child process after vfork is undefined behavior as far as I can
understand.

Regards
Troels

=== modified file 'src/callproc.c'
*** src/callproc.c	2012-07-05 18:35:48 +0000
--- src/callproc.c	2012-07-06 20:05:44 +0000
***************
*** 494,502 ****
      }

    {
-     /* child_setup must clobber environ in systems with true vfork.
-        Protect it from permanent change.  */
-     register char **save_environ = environ;
      register int fd1 = fd[1];
      int fd_error = fd1;
  #ifdef HAVE_WORKING_VFORK
--- 494,499 ----
***************
*** 619,624 ****
--- 616,624 ----
        int volatile sa_must_free_volatile = sa_must_free;
        ptrdiff_t volatile sa_count_volatile = sa_count;
        unsigned char const **volatile new_argv_volatile = new_argv;
+       /* child_setup must clobber environ in systems with true vfork.
+          Protect it from permanent change.  */
+       char ** volatile save_environ = environ;

        pid = vfork ();

***************
*** 633,664 ****
        sa_must_free = sa_must_free_volatile;
        sa_count = sa_count_volatile;
        new_argv = new_argv_volatile;
-     }

!     if (pid == 0)
!       {
! 	if (fd[0] >= 0)
! 	  emacs_close (fd[0]);
  #ifdef HAVE_SETSID
! 	setsid ();
  #endif
  #if defined (USG)
! 	setpgrp ();
  #else
! 	setpgrp (pid, pid);
  #endif /* USG */

! 	/* GConf causes us to ignore SIGPIPE, make sure it is restored
! 	   in the child.  */
! 	signal (SIGPIPE, SIG_DFL);
  #ifdef HAVE_WORKING_VFORK
! 	pthread_sigmask (SIG_SETMASK, &procmask, 0);
  #endif

! 	child_setup (filefd, fd1, fd_error, (char **) new_argv,
! 		     0, current_dir);
!       }
!
      UNBLOCK_INPUT;

  #ifdef HAVE_WORKING_VFORK
--- 633,664 ----
        sa_must_free = sa_must_free_volatile;
        sa_count = sa_count_volatile;
        new_argv = new_argv_volatile;

!       if (pid == 0)
!         {
!           if (fd[0] >= 0)
!             emacs_close (fd[0]);
  #ifdef HAVE_SETSID
!           setsid ();
  #endif
  #if defined (USG)
!           setpgrp ();
  #else
!           setpgrp (pid, pid);
  #endif /* USG */

!           /* GConf causes us to ignore SIGPIPE, make sure it is restored
!              in the child.  */
!           signal (SIGPIPE, SIG_DFL);
  #ifdef HAVE_WORKING_VFORK
!           pthread_sigmask (SIG_SETMASK, &procmask, 0);
  #endif

!           child_setup (filefd, fd1, fd_error, (char **) new_argv,
!                        0, current_dir);
!         }
!       environ = save_environ;
!     }
      UNBLOCK_INPUT;

  #ifdef HAVE_WORKING_VFORK
***************
*** 673,681 ****
      if (fd_error >= 0)
        emacs_close (fd_error);
  #endif /* not MSDOS */
-
-     environ = save_environ;
-
      /* Close most of our fd's, but not fd[0]
         since we will use that to read input from.  */
      emacs_close (filefd);
--- 673,678 ----

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

From: Daniel Colascione <dancol <at> dancol.org>
To: Troels Nielsen <bn.troels <at> gmail.com>
Cc: 8705 <at> debbugs.gnu.org, Vincent Lefevre <vincent <at> vinc17.net>
Subject: Re: bug#8705: 23.3; Emacs occasionally crashes (segfault) just after
	starting it
Date: Fri, 06 Jul 2012 15:51:58 -0700

[Message part 1 (text/plain, inline)]

On 7/6/2012 1:32 PM, Troels Nielsen wrote:
> It appears this is due to Fcall_process not restoring environ before
> after UNBLOCK_INPUT. This is too late in your case.
> 
> The patch below against trunk, ought to fix it with minimal
> intervention. But I think a better fix would be to abandon the use of
> vfork and just use fork (which should be almost as fast), as the work
> in the child process after vfork is undefined behavior as far as I can
> understand.

Better yet, we can use posix_spawn, falling back to gnulib's
implementation of posix_spawn in terms of fork or vfork. Unfortunately,
posix_spawn has no way of telling the child to setsid, so the best we
could do would be setpgrp. I have patches to use posix_spawn in the
call_process case, but not the async case.

I'm not entirely sure how much of a difference avoiding setsid makes. In
the meantime, retaining support for vfork would be nice, because on some
platforms, like Cygwin, fork is still very slow.

[signature.asc (application/pgp-signature, attachment)]

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

From: Troels Nielsen <bn.troels <at> gmail.com>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 8705 <at> debbugs.gnu.org, Vincent Lefevre <vincent <at> vinc17.net>
Subject: Re: bug#8705: 23.3; Emacs occasionally crashes (segfault) just after
	starting it
Date: Sat, 7 Jul 2012 17:08:18 +0200

> Better yet, we can use posix_spawn, falling back to gnulib's
> implementation of posix_spawn in terms of fork or vfork. Unfortunately,
> posix_spawn has no way of telling the child to setsid, so the best we
> could do would be setpgrp. I have patches to use posix_spawn in the
> call_process case, but not the async case.
>
> I'm not entirely sure how much of a difference avoiding setsid makes. In
> the meantime, retaining support for vfork would be nice, because on some
> platforms, like Cygwin, fork is still very slow.
>

Yes, looking into the problem more deeply I realize that the patch is
wrong. In fact it only substitutes one race condition for a more
severe one.

posix_spawn may be the right thing but I don't know how broadly available it is.

Another possibility would be using vfork+execle, as far as I can see
it is standardized, has been available for quite some time and it
won't make problems with setsid. The use of execvp is likely just due
to the age of these parts.

Regards
Troels

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

From: Vincent Lefevre <vincent <at> vinc17.net>
To: 8705 <at> debbugs.gnu.org
Subject: bug#8705: 23.3; Emacs occasionally crashes (segfault) just after
 starting it
Date: Mon, 22 Sep 2014 15:06:21 +0200

Any news on this bug? Debian's GNU Emacs 24.3.1 is still affected.

I get even more crashes (up to around 100% of the time under some
conditions) with gtk+ 3.13.9:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762438

but I'm not sure whether this is exactly the same bug (the crashes
just occur at the same place).

I haven't tried the patch yet.

-- 
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Vincent Lefevre <vincent <at> vinc17.net>
Cc: 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: 23.3;
 Emacs occasionally crashes (segfault) just after starting it
Date: Sat, 27 Sep 2014 00:10:18 -0400

> Any news on this bug? Debian's GNU Emacs 24.3.1 is still affected.

Same question here.


        Stefan

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 8705 <at> debbugs.gnu.org, Vincent Lefevre <vincent <at> vinc17.net>
Subject: Re: bug#8705: 23.3;
 Emacs occasionally crashes (segfault) just after starting it
Date: Thu, 09 Oct 2014 16:03:13 -0400

Stefan Monnier wrote:

>> Any news on this bug? Debian's GNU Emacs 24.3.1 is still affected.
>
> Same question here.
 

Comments from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699325#17:


> What emacs appears to be doing is:
> 
> * vfork() in thread A
>   - parent: thread A suspended
>   - parent: threads B, C, ... (one of which is the Gtk GUI) continue
>   - child: "shares all memory with its parent, including the stack"
>     per vfork(2)
> 
> * child copies environ and modifies the copy as needed
> 
> RACE:
> child + parent thread A:
>   * changes the global environ pointer, potentially making it point to
>     a new mmap() that only exists in the child process (or something?)
>   * child: calls execvp()
>   * parent: thread A resumes and puts the old environ back
> parent threads B, C...
>   * threads B, C, ... continue their work and might call getenv()
> 
> If the child wins the race, everything's OK; if the parent's threads B,
> C... "win" the race, everything explodes. It seems that Gtk, in the
> parent's GUI thread, is now more likely to "win" the race and crash,
> because new features like touchscreen support have the side-effect that
> it calls getenv() more often.
> 
> On the upstream emacs bug, Troels Nielsen wrote:
> > In the meantime, retaining support for vfork would be nice, because
> > on some platforms, like Cygwin, fork is still very slow
> 
> but on Linux (and hopefully also *BSD and Hurd), fork() is quite fast,
> and considerably less crashy. I would suggest changing the vfork() call
> to fork(), making sure the environ rewriting is only done in the child
> side of the fork(), and seeing whether that helps.
> 
> Alternatively, emacs could use execvpe() instead of execve() on
> platforms where it exists (including all GNU platforms as far as I
> know), so that it does not need to alter the value of environ at all on
> such platforms. I think that would fix this?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 8705 <at> debbugs.gnu.org
Cc: 699325 <at> bugs.debian.org
Subject: Re: Emacs 24.3 occasionally crashes (segfault) just after starting it
Date: Sat, 11 Oct 2014 19:40:50 -0700

The failure scenario described in <https://bugs.debian.org/699325#17> was fixed 
in Emacs trunk bzr 111064; see Bug#13054 <http://bugs.gnu.org/13054>.  This fix 
is in the next Emacs release, and the fix should be easily backportable to older 
Emacs releases.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 8705-done <at> debbugs.gnu.org
Cc: 699325 <at> bugs.debian.org
Subject: Re: Emacs 24.3 occasionally crashes (segfault) just after starting it
Date: Sat, 11 Oct 2014 23:19:21 -0700

I audited the Emacs trunk source code for getenv-related races that have 
undefined behavior and could have the reported symptoms.  I found some other 
races and installed a fix for them as Emacs trunk bzr 118095.  I expect this 
patch to be harder to backport to older Emacs versions, and less urgent as the 
races appear to be less likely.

Since we have fixes installed in the trunk I'll take the liberty of closing the 
Emacs bug report.  Please let us know if the bug occurs even with the fixes; if 
that happens I plan to reopen the bug report and look into it further.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 699325 <at> bugs.debian.org, 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: Emacs 24.3 occasionally crashes (segfault) just after
 starting it
Date: Tue, 14 Oct 2014 14:36:52 -0400

> fixed in Emacs trunk bzr 111064; see Bug#13054 <http://bugs.gnu.org/13054>.
> This fix is in the next Emacs release, and the fix should be easily

Hmm... if it's in trunk it's not going to be in 24.4, so not in the next
release, right?


        Stefan

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: Emacs 24.3 occasionally crashes (segfault) just after
 starting it
Date: Tue, 14 Oct 2014 14:44:07 -0400

Stefan Monnier wrote:

>> fixed in Emacs trunk bzr 111064; see Bug#13054 <http://bugs.gnu.org/13054>.
>> This fix is in the next Emacs release, and the fix should be easily
>
> Hmm... if it's in trunk it's not going to be in 24.4, so not in the next
> release, right?

Trunk from 2 years ago. Actually the cited change was in 24.3.

(This is the point when I again ask people to include the "Version:" tag
when they close a bug.)

But since https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699325
claims to be also present in 24.3, that change cannot have fixed it.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: Emacs 24.3 occasionally crashes (segfault) just after
 starting it
Date: Tue, 14 Oct 2014 14:45:55 -0400

Glenn Morris wrote:

> But since https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699325
> claims to be also present in 24.3, that change cannot have fixed it.

Oh hey, it's in the subject of this mail too.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 8705 <at> debbugs.gnu.org
Subject: Re: bug#8705: Emacs 24.3 occasionally crashes (segfault) just after
 starting it
Date: Tue, 14 Oct 2014 14:52:02 -0400

Glenn Morris wrote:

> Stefan Monnier wrote:
>
>>> fixed in Emacs trunk bzr 111064; see Bug#13054 <http://bugs.gnu.org/13054>.
>>> This fix is in the next Emacs release, and the fix should be easily
>>
>> Hmm... if it's in trunk it's not going to be in 24.4, so not in the next
>> release, right?
>
> Trunk from 2 years ago. Actually the cited change was in 24.3.

Whoops, no it wasn't. But it will be in 24.4.

I got confused by the fact that it appears in src/ChangeLog.12 dated
before the "Version 24.3 released" statement.

I did say that merging those ChangeLog "version foo released" statements
between branches would confuse people in just this way; I still think
that.

http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00990.html

Previous Next

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