annoying behavior of emacs --daemon

annoying behavior of emacs --daemon

[Miles Bader]

When using --daemon, you initially have no frames.  You can then make
new frames with emacsclient -c or emacsclient -t, but if they're X
frames, closing the last such created frame (with C-x # or C-x C-c)
kills the emacs process!

This _doesn't_ happen if you use emacsclient -t, because it specifically
overrides those commands to do something reasonable.

It seems like all emacsclient -c created frames should use some similar
magic to what emacsclient -t uses, to prevent this annoying behavior.

-Miles

-- 
White, adj. and n. Black.

Re: annoying behavior of emacs --daemon

[Dan Nicolaescu]

Miles Bader <miles.bader@necel.com> writes:

  > When using --daemon, you initially have no frames.  You can then make
  > new frames with emacsclient -c or emacsclient -t, but if they're X
  > frames, closing the last such created frame (with C-x # or C-x C-c)
  > kills the emacs process!
  > 
  > This _doesn't_ happen if you use emacsclient -t, because it specifically
  > overrides those commands to do something reasonable.
  > 
  > It seems like all emacsclient -c created frames should use some similar
  > magic to what emacsclient -t uses, to prevent this annoying behavior.

I can't reproduce this...

Can you reproduce this with 
emacs -Q --daemon
?

Re: annoying behavior of emacs --daemon

[Miles Bader]

Dan Nicolaescu <dann@ics.uci.edu> writes:
>   > When using --daemon, you initially have no frames.  You can then make
>   > new frames with emacsclient -c or emacsclient -t, but if they're X
>   > frames, closing the last such created frame (with C-x # or C-x C-c)
>   > kills the emacs process!
>
> I can't reproduce this...
>
> Can you reproduce this with 
> emacs -Q --daemon
> ?

Sure:

   $ emacs --daemon -Q 
   ("emacs" "-Q")
   For information about GNU Emacs and the GNU system, type C-h C-a.
   $ pidof emacs
   9730 9424
   $ emacsclient -c ~/.bashrc 
   Waiting for Emacs...
   <... close emacs window with C-x C-c or C-x # ...>
   $ pidof emacs
   9424

[The 9424 process is my normal long-lived emacs process, but emacsclient
seems to connect to the last-started process.]

If I use emacsclient -t, on the other hand:

   $ emacs --daemon -Q 
   ("emacs" "-Q")
   For information about GNU Emacs and the GNU system, type C-h C-a.
   $ pidof emacs
   9744 9424
   $ emacsclient -t ~/.bashrc 
   <... close emacs window with C-x C-c or C-x # ...>
   $ pidof emacs
   9744 9424

The same thing happens whether I kill the window with C-x C-c (bound to
`save-buffers-kill-terminal'), or C-x # (bound to `server-edit').

Emacs is checked out from CVS this morning.

-Miles

-- 
Immortality, n.  A toy which people cry for, And on their knees apply for,
      Dispute, contend and lie for, And if allowed Would be right proud
      Eternally to die for.

Re: annoying behavior of emacs --daemon

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >   > When using --daemon, you initially have no frames.  You can then make
  > >   > new frames with emacsclient -c or emacsclient -t, but if they're X
  > >   > frames, closing the last such created frame (with C-x # or C-x C-c)
  > >   > kills the emacs process!
  > >
  > > I can't reproduce this...
  > >
  > > Can you reproduce this with 
  > > emacs -Q --daemon
  > > ?
  > 
  > Sure:
  > 
  >    $ emacs --daemon -Q 
  >    ("emacs" "-Q")
  >    For information about GNU Emacs and the GNU system, type C-h C-a.
  >    $ pidof emacs
  >    9730 9424
  >    $ emacsclient -c ~/.bashrc 
  >    Waiting for Emacs...
  >    <... close emacs window with C-x C-c or C-x # ...>
  >    $ pidof emacs
  >    9424
  > 
  > [The 9424 process is my normal long-lived emacs process, but emacsclient
  > seems to connect to the last-started process.]
  > 
  > If I use emacsclient -t, on the other hand:
  > 
  >    $ emacs --daemon -Q 
  >    ("emacs" "-Q")
  >    For information about GNU Emacs and the GNU system, type C-h C-a.
  >    $ pidof emacs
  >    9744 9424
  >    $ emacsclient -t ~/.bashrc 
  >    <... close emacs window with C-x C-c or C-x # ...>
  >    $ pidof emacs
  >    9744 9424
  > 
  > The same thing happens whether I kill the window with C-x C-c (bound to
  > `save-buffers-kill-terminal'), or C-x # (bound to `server-edit').
  > 
  > Emacs is checked out from CVS this morning.

I still cannot reproduce this, with emacs freshly checked out and after
a "make maintainer-clean" and /bin/rm -f /tmp/emacs*/server

Can you please try to debug and find out why emacs dies for you?

Re: annoying behavior of emacs --daemon

[Miles Bader]

On Tue, Nov 4, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
>  > >   > When using --daemon, you initially have no frames.  You can then make
>  > >   > new frames with emacsclient -c or emacsclient -t, but if they're X
>  > >   > frames, closing the last such created frame (with C-x # or C-x C-c)
>  > >   > kills the emacs process!
>
> I still cannot reproduce this, with emacs freshly checked out and after
> a "make maintainer-clean" and /bin/rm -f /tmp/emacs*/server
>
> Can you please try to debug and find out why emacs dies for you?

Hmm, it seems to segfault in xlib, though I'm not sure why.  I'm using
a gtk emacs; are you also?

1509	    if (terminal->reference_count == 0)
(gdb) n
1515		Fdelete_terminal (tmp, NILP (force) ? Qt : force);
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0xb780dfc0 in _XSend () from /usr/lib/libX11.so.6
(gdb) ba
#0  0xb780dfc0 in _XSend () from /usr/lib/libX11.so.6
#1  0xb780e1b2 in _XFlush () from /usr/lib/libX11.so.6
#2  0xb77e5d71 in XFlush () from /usr/lib/libX11.so.6
#3  0xb7839700 in ?? () from /usr/lib/libX11.so.6
#4  0x0881a940 in ?? ()
#5  0xb78b53ec in ?? () from /usr/lib/libX11.so.6
#6  0xbfffb188 in ?? ()
#7  0xb7838de2 in _XimFlush () from /usr/lib/libX11.so.6
Backtrace stopped: frame did not save the PC

Lisp Backtrace:
"delete-frame" (0xbfffc374)
"server-delete-client" (0xbfffc4b4)
"server-save-buffers-kill-terminal" (0xbfffc5e4)
"save-buffers-kill-terminal" (0xbfffc764)
"call-interactively" (0xbfffc924)

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: annoying behavior of emacs --daemon

[Liang Wang]

On Tue, Nov 4, 2008 at 5:47 PM, Miles Bader <miles@gnu.org> wrote:
>
> On Tue, Nov 4, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> >  > >   > When using --daemon, you initially have no frames.  You can then make
> >  > >   > new frames with emacsclient -c or emacsclient -t, but if they're X
> >  > >   > frames, closing the last such created frame (with C-x # or C-x C-c)
> >  > >   > kills the emacs process!
> >
> > I still cannot reproduce this, with emacs freshly checked out and after
> > a "make maintainer-clean" and /bin/rm -f /tmp/emacs*/server
> >
> > Can you please try to debug and find out why emacs dies for you?
>
> Hmm, it seems to segfault in xlib, though I'm not sure why.  I'm using
> a gtk emacs; are you also?
>
> 1509        if (terminal->reference_count == 0)
> (gdb) n
> 1515            Fdelete_terminal (tmp, NILP (force) ? Qt : force);
> (gdb) n
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb780dfc0 in _XSend () from /usr/lib/libX11.so.6
> (gdb) ba
> #0  0xb780dfc0 in _XSend () from /usr/lib/libX11.so.6
> #1  0xb780e1b2 in _XFlush () from /usr/lib/libX11.so.6
> #2  0xb77e5d71 in XFlush () from /usr/lib/libX11.so.6
> #3  0xb7839700 in ?? () from /usr/lib/libX11.so.6
> #4  0x0881a940 in ?? ()
> #5  0xb78b53ec in ?? () from /usr/lib/libX11.so.6
> #6  0xbfffb188 in ?? ()
> #7  0xb7838de2 in _XimFlush () from /usr/lib/libX11.so.6
> Backtrace stopped: frame did not save the PC
>
> Lisp Backtrace:
> "delete-frame" (0xbfffc374)
> "server-delete-client" (0xbfffc4b4)
> "server-save-buffers-kill-terminal" (0xbfffc5e4)
> "save-buffers-kill-terminal" (0xbfffc764)
> "call-interactively" (0xbfffc924)
>
> -Miles
> --
> Do not taunt Happy Fun Ball.
>
>

I got same problem.  And I found a patch at
http://www.nabble.com/segfault-when-using-XIM-with-multi-tty-on-gnu-linux-td18966793.html.
 It works for me.

Re: annoying behavior of emacs --daemon

[Miles Bader]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

"Liang Wang" <netcasper@gmail.com> writes:
>> Hmm, it seems to segfault in xlib, though I'm not sure why.  I'm using
>> a gtk emacs; are you also?
>
> I got same problem.  And I found a patch at
> http://www.nabble.com/segfault-when-using-XIM-with-multi-tty-on-gnu-linux-td18966793.html.
>  It works for me.

Ah, that patch fixes the problem for me too!  Thank you!

[I've attached a version of the patch which applies correctly
(nabble mucks up the whitespace).]

-Miles


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch to fix xlib crash --]
[-- Type: text/x-diff, Size: 487 bytes --]

--- orig/src/xterm.c
+++ mod/src/xterm.c
@@ -8319,9 +8319,11 @@
 	XUnregisterIMInstantiateCallback (dpyinfo->display, dpyinfo->xrdb,
 					  NULL, EMACS_CLASS,
 					  xim_instantiate_callback, NULL);
-#endif /* not HAVE_X11R6_XIM */
+#else /* not HAVE_X11R6_XIM */
+      /* if we have X11R6 xim, this causes a double-free */
       if (dpyinfo->display)
 	XCloseIM (dpyinfo->xim);
+#endif /* not HAVE_X11R6_XIM */
       dpyinfo->xim = NULL;
       XFree (dpyinfo->xim_styles);
     }

[-- Attachment #3: Type: text/plain, Size: 127 bytes --]



-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: annoying behavior of emacs --daemon

[Chong Yidong]

Miles Bader <miles@gnu.org> writes:

> "Liang Wang" <netcasper@gmail.com> writes:
>>> Hmm, it seems to segfault in xlib, though I'm not sure why.  I'm using
>>> a gtk emacs; are you also?
>>
>> I got same problem.  And I found a patch at
>> http://www.nabble.com/segfault-when-using-XIM-with-multi-tty-on-gnu-linux-td18966793.html.
>>  It works for me.
>
> Ah, that patch fixes the problem for me too!  Thank you!
>
> [I've attached a version of the patch which applies correctly
> (nabble mucks up the whitespace).]

I've applied the patch.  Thanks.

Re: annoying behavior of emacs --daemon

[Dan Nicolaescu]

"Miles Bader" <miles@gnu.org> writes:

  > On Tue, Nov 4, 2008 at 5:55 PM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > >  > >   > When using --daemon, you initially have no frames.  You can then make
  > >  > >   > new frames with emacsclient -c or emacsclient -t, but if they're X
  > >  > >   > frames, closing the last such created frame (with C-x # or C-x C-c)
  > >  > >   > kills the emacs process!
  > >
  > > I still cannot reproduce this, with emacs freshly checked out and after
  > > a "make maintainer-clean" and /bin/rm -f /tmp/emacs*/server
  > >
  > > Can you please try to debug and find out why emacs dies for you?
  > 
  > Hmm, it seems to segfault in xlib, though I'm not sure why.  I'm using
  > a gtk emacs; are you also?

I also tried gtk (gtk2-2.12.12), it worked fine.  What version of gtk
are you using?
We know there are problems with versions before 2.10 
(see emacs/admin/notes/multi-tty)

Re: annoying behavior of emacs --daemon

[Miles Bader]

On Wed, Nov 5, 2008 at 12:12 AM, Dan Nicolaescu <dann@ics.uci.edu> wrote:
> I also tried gtk (gtk2-2.12.12), it worked fine.  What version of gtk
> are you using?
> We know there are problems with versions before 2.10

gtk 2.12.11

But see the more recent messages on this thread -- it seems to have
something to do with xim.

-Miles

-- 
Do not taunt Happy Fun Ball.

unclear [was: annoying] behavior of emacs --daemon

[Stephen J. Turnbull]

Miles Bader writes:

 >    $ emacs --daemon -Q 
 >    ("emacs" "-Q")
 >    For information about GNU Emacs and the GNU system, type C-h C-a.

Now that seems like bad advice in daemon mode.  Even bash is unlikely
to do the right thing here. :-)  How about

C-h C-a in an Emacs frame gives information about GNU Emacs and the GNU system.

or of course,

For information about GNU Emacs and the GNU system, type C-h C-a in an
Emacs frame.

but that takes up two lines instead of one.

Re: unclear

[Chong Yidong]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Miles Bader writes:
>
>  >    $ emacs --daemon -Q 
>  >    ("emacs" "-Q")
>  >    For information about GNU Emacs and the GNU system, type C-h C-a.
>
> Now that seems like bad advice in daemon mode.  Even bash is unlikely
> to do the right thing here. :-)

Good point.  I changed the message, in daemon mode, to just say
"Starting Emacs daemon."

Thanks.

Re: unclear

[Ulrich Mueller]

>>>>> On Mon, 20 Oct 2008, Chong Yidong wrote:

> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>>  >    $ emacs --daemon -Q 
>>  >    ("emacs" "-Q")
>>  >    For information about GNU Emacs and the GNU system, type C-h C-a.
>>
>> Now that seems like bad advice in daemon mode.  Even bash is unlikely
>> to do the right thing here. :-)

> Good point.  I changed the message, in daemon mode, to just say
> "Starting Emacs daemon."

Hm, for me it still says:

,----
| $ emacs --daemon -Q
| ("emacs" "-Q")
| Starting Emacs daemon.
`----

I wonder if the first line of output, i.e. the (incomplete) list of
command line arguments, would be useful for anybody? If not, then it
should be suppressed, too.

Ulrich

--- lisp/startup.el~
+++ lisp/startup.el
@@ -626,5 +626,6 @@
 (defun tty-handle-args (args)
   (let (rest)
-    (message "%S" args)
+    (or (daemonp)
+	(message "%S" args))
     (while (and args
 		(not (equal (car args) "--")))