--- Begin Message ---
|
Subject: |
emacsclient -c crashes emacs --daemon intermittently; have strace |
|
Date: |
Mon, 29 Mar 2010 15:08:21 -0700 |
I am trying to set myself up using emacs --daemon so that I can easily
manage multiple emacs frames within one process. However, I have hit a
significant stumbling block. If I run emacs --daemon (or emacs -nw and
then do (server-start) ) and then repeatedly run emacsclient -c and
clost the resulting window, emacs will randomly crash. Sometimes it
happens on the first time that I run emacsclient -c, sometimes on the
20th.
I use Ubuntu 9.10, and I have reported this bug in Launchpad. However,
I have also compiled both emacs 23.1 and trunk from vanilla sources,
and both of these exhibit the same bug as the Ubuntu-packaged
versions.
I have generated some stack traces by the following procedure, as
described at https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/543611
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 emacs -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.
I tried sending this message with one of the traces attached, but I
guess it was too large. Please reply to tell me how I can send a
trace.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#5802: emacsclient -c crashes emacs --daemon intermittently; have strace |
|
Date: |
Thu, 8 Apr 2010 23:11:28 -0700 (PDT) |
Ryan Thompson <address@hidden> writes:
> On Thu, Apr 1, 2010 at 12:50 PM, Dan Nicolaescu <address@hidden> wrote:
> > Ryan Thompson <address@hidden> writes:
> >
> >> On Tue, Mar 30, 2010 at 10:47 AM, Dan Nicolaescu <address@hidden> wrote:
> >>> Ryan Thompson <address@hidden> writes:
> >>>
> >>>> On Tue, Mar 30, 2010 at 8:46 AM, Dan Nicolaescu <address@hidden> wrote:
> >>>>> Ryan Thompson <address@hidden> writes:
> >>>>>
> >>>>>> I am trying to set myself up using emacs --daemon so that I can
easily
> >>>>>> manage multiple emacs frames within one process. However, I have hit
a
> >>>>>> significant stumbling block. If I run emacs --daemon (or emacs -nw
and
> >>>>>> then do (server-start) ) and then repeatedly run emacsclient -c and
> >>>>>> clost the resulting window, emacs will randomly crash. Sometimes it
> >>>>>> happens on the first time that I run emacsclient -c, sometimes on the
> >>>>>> 20th.
> >>>>>>
> >>>>>> I use Ubuntu 9.10, and I have reported this bug in Launchpad.
However,
> >>>>>> I have also compiled both emacs 23.1 and trunk from vanilla sources,
> >>>>>> and both of these exhibit the same bug as the Ubuntu-packaged
> >>>>>> versions.
> >>>>>>
> >>>>>> I have generated some stack traces by the following procedure, as
> >>>>>> described at
https://bugs.launchpad.net/ubuntu/+source/emacs23/+bug/543611
> >>>>>>
> >>>>>> 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 emacs -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.
> >>>>>
> >>>>> This is very likely due to a long standing bug in Gtk+, see:
> >>>>> http://bugzilla.gnome.org/show_bug.cgi?id=85715
> >>>>>
> >>>>> Please compile emacs using
> >>>>>
> >>>>> ./configure --with-x-toolkit=lucid
> >>>>>
> >>>>> and try to reproduce the problem you are seeing with that emacs.
> >>>>>
> >>>>
> >>>> I tried that; same problem. Would you like a stack trace?
> >>>
> >>> Sure, for the lucid version please.
> >>> But please get the stack trace using by attaching gdb to emacs.
> >>> See etc/DEBUG for more info.
> >>>
> >>> Also, please start emacs using "emacs -Q"
> >>>
> >>>
> >>>
> >>
> >> I tried to figure out gdb, but I couldn't figure it out in the time I
> >> had. But I have been running all my tests with -Q. I'll try again when
> >> I have more time to mess around with it.
> >
> > cd emacs/src
> > gdb ./emacs
> > run -Q -nw -f server-start
> >
> >
> > do whatever you do to to crash emacs, and when that happens type
> >
> > xbacktrace
> >
> > in gdb
> >
> > Again, this is only useful for the version compiled using ./configure
--with-x-toolkit=lucid
> >
>
> 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.
>
> When the lucid version, emacs does not crash, but for some reason,
> when I run the emacsclient frame-creating loop that I described
> previously, sometimes the client frame disappears as soon as it
> appears, and I assumed that a crash had occurred. But in this case,
> emacs does not crash, and I only get the problem in a loop like this.
> Simply running "emacsclient -c" manually over and over at the
> command-line never causes a frame to disappear. So, I think I will
> move forward using the lucid version, and you can mark this as a GTK
> problem.
>
> Thanks for your patience.
Closing this the, we have plenty of similar reports.
--- End Message ---