Re: emacs daemon exits when emacsclient connects to it again

[Giorgos Keramidas]

On Mon, 9 Feb 2009 18:29:41 +0800, Liang Wang <address@hidden> wrote:
> On Mon, Feb 9, 2009 at 5:47 PM, Giorgos Keramidas
> <address@hidden> wrote:
>> On Mon, 9 Feb 2009 17:11:45 +0800, Liang Wang <address@hidden> wrote:
>>> Emacs daemon exits or crashes when emacsclient connect to it again.
>>> Below is my command line operation.
>>>
>>> address@hidden ~]$ emacs --daemon -Q
>>> ("emacs" "-Q")
>>> Starting Emacs daemon.
>>> address@hidden ~]$ pgrep -l emacs
>>> 2813 emacs
>>> address@hidden ~]$ emacsclient -c    # succeed to connect
>>> Waiting for Emacs...
>>> address@hidden ~]$ pgrep -l emacs
>>> 2813 emacs
>>> address@hidden ~]$ emacsclient -c    # fail to connect
>>> Waiting for Emacs...
>>> address@hidden ~]$ pgrep -l emacs
>>> address@hidden ~]$
>>
>> Which version of Emacs are you running?  Can you attach to the
>> background process using gdb and see where it crashes?
>
> GNU Emacs 23.0.90.1 (i686-pc-linux-gnu, GTK+ Version 2.14.7) of
> 2009-02-09 on localhost.localdomain
>
> I am not familiar with gdb.  Below is the output of gdb session.  It
> seems that something is wrong when emacsclient connects to daemon
> initially.

Thanks for looking into this nevertheless :)

> (gdb) attach 2970
[...]
> (gdb) c
> Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000003 in ?? ()
> (gdb) bt
> #0  0x00000003 in ?? ()
> #1  0x00000007 in ?? ()
> #2  0xbfec0490 in ?? ()
> #3  0x009b025c in freopen64 () from /lib/libglib-2.0.so.0
> #4  0x009b025c in freopen64 () from /lib/libglib-2.0.so.0
> #5  0x00000004 in ?? ()
> #6  0xbfec0418 in ?? ()
> #7  0x00928c0a in g_string_append_vprintf () from /lib/libglib-2.0.so.0
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> (gdb)

This part looks like a crash inside the glib library.  Looking at its
path, the operating system seems to be GNU/Linux.  Can you give us a bit
more information?

  * The operating system type.
  * The branch/release of the OS you are using.
  * The list of installed packages that are related to GTK+.

This may be a bug in glib that has already been resolved upstream.  If
that is the case, then updating the packages that Emacs depends upon
might fix the crash.