Subject: Re: bug#5802: emacsclient -c crashes emacs --daemon intermittently; have strace

From: Ryan Thompson <[email-masked]>
Date: Sat, 3 Apr 2010 14:20:04 -0700

On Thu, Apr 1, 2010 at 12:50 PM, Dan Nicolaescu <[email-masked]> wrote:
> Ryan Thompson <[email-masked]> writes:
>
>> On Tue, Mar 30, 2010 at 10:47 AM, Dan Nicolaescu <[email-masked]> wrote:
>>> Ryan Thompson <[email-masked]> writes:
>>>
>>>> On Tue, Mar 30, 2010 at 8:46 AM, Dan Nicolaescu <[email-masked]> wrote:
>>>>> Ryan Thompson <[email-masked]> 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.