emacsclient -c randomly crashes emacs about 1 in every 5 to 10 times

[Ryan Thompson]

Binary package hint: emacs23

I am trying to start using emacs --daemon and emacsclient, so that I can easily have multiple emacs windows sharing a single process. However, my attempts are frustrated by the fact that when I use "emacsclient -c" to create a new window in an exising emacs session, emacs crashes about 1 in 5 times. It seems completely random.

Here's what I've been using to reproduce this:

x=0; emacs23 -Q --daemon &>/dev/null; while emacsclient -c &>/dev/null; do x=$(( $x + 1 )); done; echo "Created $x windows before crash."

That will start the daemon, and then keep spawning new emacs windows as long as the daemon is running. Just keep closing the windows, and new ones will pop up. Every time I do this command, I get a different number of windows before emacs crashes. On my last five tries, I have gotten 7, 17, 12, 18, and 24 windows. Hence my claim of randomness.

ProblemType: Bug
Architecture: amd64
Date: Sun Mar 21 10:34:10 2010
DistroRelease: Ubuntu 9.10
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
NonfreeKernelModules: nvidia wl
Package: emacs23 23.1+1-4ubuntu3.1
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/zsh
ProcVersionSignature: Ubuntu 2.6.31-13bfsbfq1.43-generic
SourcePackage: emacs23
Uname: Linux 2.6.31-13bfsbfq1-generic x86_64

[Ryan Thompson (rct86)]

I tried downloading and compiling the version in Lucid Lynx (23.1+1-4ubuntu6), and it has the same problem.

I also tried using the lucid toolkit version instead of the gtk version. Same issue.

[Ryan Thompson (rct86)]

More info:

I had a friend attempt to reproduce this on his computer and he said this:
"The emacs daemon seems fine with Fedora 12 and emacs 23.1.1. It never crashed and got 60 and 58 on two runs before giving up."

Also, if I do the following, I also get a crash in a short time:

1. Open two teminals
2. In Terminal 1, run "emacs -nw" to start of a text-mode emacs session.
3. Run "(server-start)" in the emacs session.
4. In terminal 2: x=0; while emacsclient -c &>/dev/null; do x=$(( $x + 1 )); done; echo "Created $x windows before crash."

However, if I start a *graphical* emacs session and then keep running emacsclient -c, I do *not* get a crash.

[Ryan Thompson (rct86)]

More info: I tried compiling the versions of emacs in Lucid and Debian testing, using debuild, on Karmic. Same problem with both. Next I will try compiling from source, with no debian modifications.

[Ryan Thompson (rct86)]

I compiled vanilla emacs trunk, version 24.0.50.1, with no debian patches. It did not exhibit the bug. Since neither my vanilla emacs nor my friend's Fedora emacs exhibit this bug and all debian-derived versions that I have tested so far do exhibit the bug, signs seem to point to this being a problem with the debian packaging of emacs.

[Ryan Thompson (rct86)]

I suppose I will try disabling the debian patches one by one and recompiling until the problem goes away.

If I can figure out how to do that.

[Ryan Thompson (rct86)]

Cancel the last few statements. When I used the debian-selected configure options on the vanilla sources (either 23.1 or trunk), I got the same problem. I am now in the process of disabling the debian-selected args one-by-one.

[Ryan Thompson (rct86)]

I have straces! I will now upload them.

[Ryan Thompson (rct86)]

Note: to generate this trace, I use the following procedure:

Open two terminals. In the first terminal, run the following commands to start emacs with strace:

$ mkdir -p /tmp/emacs-strace
$ strace -o /tmp/emacs-strace/trace-`date +%s`.log emacs23 -Q -nw

When emacs has started, do M-x server-start so that emacsclient can work. Now, in the second terminal, run the following command:

$ x=0; while emacsclient -c ; do x=$(( $x + 1 )); done; echo "Created $x windows before crash."

Now, an emacs window will open. Close it. Each time you close a window, a new emacs window will open. Keep closing each one that appears. If emacs exhibits the bug, then eventually you will close one window, and emacs will crash when it tries to create the next one. At this point, you can go get your stack trace in /tmp/emacs-strace.

I have generated several traces in this way, and in each one, the last 50 lines are identical except that certain hexadecimal numbers have changed. Let me know if you want more traces.

[Ryan Thompson (rct86)]

Does anyone have a comment on this? Am I reporting this to the wrong place?

[Ryan Thompson (rct86)]

I have reported this bug upstream: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5802

[Ryan Thompson (rct86)]

On further inspection, I can no longer reproduce the crash
--with-x-toolkit=lucid. The segfault in the gtk version occurs in
"gdk_screen_get_display," from /usr/lib/libgdk-x11-2.0.so.0, which is
in Ubuntu package libgtk2.0-0 version 2.18.3-1ubuntu2.2.

Would you like a full backtrace?

[Reinhard Tartler (siretart)]

On Sat, Apr 03, 2010 at 23:31:22 (CEST), Ryan Thompson wrote:

> On further inspection, I can no longer reproduce the crash
> --with-x-toolkit=lucid. The segfault in the gtk version occurs in
> "gdk_screen_get_display," from /usr/lib/libgdk-x11-2.0.so.0, which is
> in Ubuntu package libgtk2.0-0 version 2.18.3-1ubuntu2.2.
>
> Would you like a full backtrace?

yes, a backtrace would indeed be helpful. Without really knowing what's
going on, I think a valgrind report might be helpful as well!

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Ryan Thompson (rct86)]

On the emacs upstream report that I filed, Dan suggests that this is a known problem die to this long-standing GTK+ bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715

I'll get the backtrace soon. I've never used valgrind, so I'm not sure how to do that.

[Ryan Thompson (rct86)]

Here's a backtrace from vanilla emacs 23. It's the same crash in the emacs version from karmic, lucid, squeeze, sid, vanilla upstream release, and upstream trunk.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Mingming Ren (portis25)]

It's been fixed upstream:

Work around GTK bug crashing emacs GTK builds.
author Tassilo Horn <email address hidden>
 Fri, 18 Nov 2011 09:36:59 +0000 (10:36 +0100)
committer Tassilo Horn <email address hidden>
 Fri, 18 Nov 2011 09:36:59 +0000 (10:36 +0100)
commit 2fbfdd56056ee387b5d07787698546a63b2167cd
tree bae36eef03213814db5b92067ef604b54b29e0bb tree | snapshot (tar.gz zip)
parent 7a42f7390dad17ded49ee3e1e39d724535471c90 commit | diff
Work around GTK bug crashing emacs GTK builds.

* frame.c (delete_frame): Don't delete the terminal when the last
X frame is closed if emacs is built with GTK toolkit.

[Ryan Thompson (rct86)]

I don't think it has been fixed. It still happens to me in recent Emacs snapshots.

[Marius B. Kotsbak (mariusko)]

The GTK bug report is reopened.

Possibly it is a workaround to install the package "emacs23-lucid" since compiling with "--with-x-toolkit=lucid" is supposed to be a workaround.

[Ryan Thompson (rct86)]

Yes, the lucid builds of emacs are what I have been using for years for exactly this reason. They don't have this problem.

[Marius B. Kotsbak (mariusko)]

Also I don't seem to be able to reproduce it using "emacsclient -nw". Is this bug just for the graphical emacs version?

[Ryan Thompson (rct86)]

There's some nuance here. This bug is GTK-related. If your emacs daemon is not compiled with gtk support (either a terminal-only version of compiled with the lucid toolkit), then you will not see this bug. Even if your emacs is compiled with gtk, you will still not see the bug unless you actually create (and then destroy) an emacs X window that uses GTK, so doing emacsclient -nw should not trigger the bug. But doing emacsclient -c with the same daemon later should still cause a crash.