Possible bug when running with --daemon on 24.3.92.3?

Possible bug when running with --daemon on 24.3.92.3?

[Alexis]

Hi all,

i've just compiled and installed 24.3.92.3 on 64-bit Debian Wheezy
(7.5). i start Emacs from URxvt with the `--daemon` option, and then
open a new frame with `emacsclient -c`. That works fine. However, when i
exit the client using C-x C-c, the server process is shut down as
well. i've tried recompiling with:

    --with-x-toolkit=lucid
    --with-x-toolkit=gtk2
    --with-x-toolkit=gtk3

but that makes no difference.

Summary of steps to reproduce:

1. emacs -q --daemon
2. emacsclient -c
3. C-x C-c
4. The `emacs --daemon` process is no longer running.


Alexis.

Possible bug when running with --daemon on 24.3.92.3?

[Stephen J. Turnbull]

Alexis writes:

 > i've just compiled and installed 24.3.92.3 on 64-bit Debian Wheezy
 > (7.5). i start Emacs from URxvt with the `--daemon` option, and
 > then open a new frame with `emacsclient -c`. That works
 > fine. However, when i exit the client using C-x C-c, the server
 > process is shut down as well.

You're not exiting the client; there is no client to exit.

In principle, the client simply sends a message to the server to open
a window for you, then exits.  (I forget what can happen in case of a
TTY client -- it may have to remain to keep a pipe open, but that's
all it does.  The principle is the same: you're editing in the server,
not in the client.)  I.e., C-x C-c is supposed to shut down the server
process.

You should be able to close the frame with C-x 5 0 or via the window
manager.

Re: Possible bug when running with --daemon on 24.3.92.3?

[Andreas Schwab]

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

> In principle, the client simply sends a message to the server to open
> a window for you, then exits.

Only if you pass --no-wait.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Possible bug when running with --daemon on 24.3.92.3?

[Alexis]

Stephen J. Turnbull writes:

> You should be able to close the frame with C-x 5 0 or via the window
> manager.

Huh. Well, in the past i've been using C-x C-c to quit the frame without
quitting the server. i gather i must have been doing something else
differently also ....

In any case, i just tried C-x 5 0: that also quit both the frame and
server.


Alexis.

Re: Possible bug when running with --daemon on 24.3.92.3?

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Tue, 08 Jul 2014 17:30:46 +0900
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> I.e., C-x C-c is supposed to shut down the server process.

That's not true, not in Emacs.  "C-x C-c" in client frames does not
kill Emacs (a.k.a. "shut down the server"), it only closes the client
frame.

Re: Possible bug when running with --daemon on 24.3.92.3?

[David Kastrup]

Alexis <flexibeast@gmail.com> writes:

> Stephen J. Turnbull writes:
>
>> You should be able to close the frame with C-x 5 0 or via the window
>> manager.
>
> Huh. Well, in the past i've been using C-x C-c to quit the frame without
> quitting the server. i gather i must have been doing something else
> differently also ....
>
> In any case, i just tried C-x 5 0: that also quit both the frame and
> server.

Sure that it did not _quit_ the frame and _crash_ the server?  I seem to
remember that only some basic toolkits (like Lucid) were capable of
detaching reliably from a graphic terminal.

-- 
David Kastrup

Re: Possible bug when running with --daemon on 24.3.92.3?

[Alexis]

David Kastrup writes:

> Sure that it did not _quit_ the frame and _crash_ the server?  I seem
> to remember that only some basic toolkits (like Lucid) were capable of
> detaching reliably from a graphic terminal.

Fair point. i'd only tried C-x C-c with multiple toolkits, not C-x 5
0. So i've just done some testing which uses both approaches.

Each time Emacs was run with `emacs -q --daemon`, followed by
`emacsclient -c`.

--with-x-toolkit=lucid

C-x 5 0: no server
C-x C-c: no server

--with-x-toolkit=gtk2

C-x 5 0: no server
C-x C-c: no server

--with-x-toolkit=gtk3

C-x 5 0: no server
C-x C-c: no server


Alexis.

Re: Possible bug when running with --daemon on 24.3.92.3?

[Peder O. Klingenberg]

On Tue, Jul 08 2014 at 09:30, Alexis wrote:

> Summary of steps to reproduce:
>
> 1. emacs -q --daemon
> 2. emacsclient -c
> 3. C-x C-c
> 4. The `emacs --daemon` process is no longer running.

The symptoms seem similar to something I saw a couple of months back.
Reported as bug #17125.  That apparently had something to do with my
fonts.

Try attaching gdb to the emacs process before starting the emacsclient,
and see if you catch a signal as you exit emacsclient?

I haven't had time to pursue that bug any further.  Dmitry Antipov
provided a patch that worked for me, but apparently had some
deficiencies.

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.

Re: Possible bug when running with --daemon on 24.3.92.3?

[Alexis]

Peder O. Klingenberg writes:

> Try attaching gdb to the emacs process before starting the
> emacsclient, and see if you catch a signal as you exit emacsclient?

When i enter C-x 5 0 in emacsclient, gdb reports:

    Program received signal SIGSEGV, Segmentation fault.
    PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
    2436          return PSEUDOVECTOR_TYPEP (h, code);


Alexis.

Re: Possible bug when running with --daemon on 24.3.92.3?

[Peder O. Klingenberg]

On Thu, Jul 10 2014 at 09:41, Alexis wrote:

> Peder O. Klingenberg writes:
>
>> Try attaching gdb to the emacs process before starting the
>> emacsclient, and see if you catch a signal as you exit emacsclient?
>
> When i enter C-x 5 0 in emacsclient, gdb reports:
>
>     Program received signal SIGSEGV, Segmentation fault.
>     PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
>     2436          return PSEUDOVECTOR_TYPEP (h, code);

So your emacs dies with a segfault, same as mine did.  But not on the
same line (or perhaps there's been code changes in that area since
march, I haven't checked).  WRT the Subject of this thread, I'd say
definitely a bug.

The next steps would be to get a backtrace, and perhaps look at some
variables, to figure out the context in which it dies.  Take a look at
etc/DEBUG in the emacs sources for tips and hints.  And then file a bug,
and either hope for the guidance of those more knowledgeable in the ways
of the source, or dig in yourself.  Wonderful learning opportunity :)


...Peder...
-- 
This must be Thursday.  I never could get the hang of Thursdays.

Re: Possible bug when running with --daemon on 24.3.92.3?

[Michael Mattie]

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

On Wednesday, July 09, 2014 09:23:10 Peder O. Klingenberg wrote:
> On Tue, Jul 08 2014 at 09:30, Alexis wrote:
> > Summary of steps to reproduce:
> > 
> > 1. emacs -q --daemon
> > 2. emacsclient -c
> > 3. C-x C-c
> > 4. The `emacs --daemon` process is no longer running.
> 
> The symptoms seem similar to something I saw a couple of months back.
> Reported as bug #17125.  That apparently had something to do with my
> fonts.
> 
> Try attaching gdb to the emacs process before starting the emacsclient,
> and see if you catch a signal as you exit emacsclient?
> 
> I haven't had time to pursue that bug any further.  Dmitry Antipov
> provided a patch that worked for me, but apparently had some
> deficiencies.
> 
> ...Peder...

I can't speak to resolve the issue proper, but I have run into many issues 
with emacs in --daemon mode dissappearing when trying to open a X frame as
seems to be occuring here.

I resolved them permanently by taking all the stuff that was X specific in the
init such as font and color and ran the .el file off a before-make-frame hook.

I set a simple binary sentinal to make sure that it only ran once.

Never had a problem since. In my thoughts if --daemon has not gathered any 
information on the X environment which makes sense then deferring execution
of configuring X stuff seems to be the only way out for now.

Here is the relevant part of my config in gitweb. Ignore my grail decorations,
the control block is quite simple and explanatory.

http://lispblivet.sx/git/?p=emacs.git;a=blob;f=emacs/grail.el;h=85e7adb6495d04a50ab6d1cd0661cd7c93e572af;hb=HEAD#l320

It might be useful in that if the workaround succeeds for the initial poster
it could narrow down the specific bits of information that emacs lacks
in --daemon mode.

How to solve it correctly is a bit beyond me, I just have a work-around to
what I think is the problem.

Mike Mattie



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Possible bug when running with --daemon on 24.3.92.3?

[Alexis]

Michael Mattie writes:

> I can't speak to resolve the issue proper, but I have run into many
> issues with emacs in --daemon mode dissappearing when trying to open a
> X frame as seems to be occuring here.

Sorry, i'm not sure i follow; in my case, the new frame opens
successfully and rapidly, and i can confirm the server process is still
running whilst emacsclient is running. Has that not been the case for
you?


Alexis.

Emacs daemon segfaults [was: Possible bug when running with --daemon on 24.3.92.3?]

[Alexis]

Peder O. Klingenberg writes:

> The next steps would be to get a backtrace, and perhaps look at some
> variables, to figure out the context in which it dies.  Take a look at
> etc/DEBUG in the emacs sources for tips and hints.  And then file a
> bug, and either hope for the guidance of those more knowledgeable in
> the ways of the source, or dig in yourself.  Wonderful learning
> opportunity :)

:-)

i've confirmed that the problem exists for me in pretests .91 and .90 as
well. i'm not a C coder, but i'll certainly check out etc/DEBUG and try
to discover some specifics about what's going on.


Alexis.

Emacs daemon segfaults [was: Possible bug when running with --daemon on 24.3.92.3?]

[Alexis]

Peder O. Klingenberg writes:

> On Thu, Jul 10 2014 at 09:41, Alexis wrote:
>
>> Peder O. Klingenberg writes:
>>
>>> Try attaching gdb to the emacs process before starting the
>>> emacsclient, and see if you catch a signal as you exit emacsclient?
>>
>> When i enter C-x 5 0 in emacsclient, gdb reports:
>>
>>     Program received signal SIGSEGV, Segmentation fault.
>>     PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
>>     2436          return PSEUDOVECTOR_TYPEP (h, code);
>
> So your emacs dies with a segfault, same as mine did.  But not on the
> same line (or perhaps there's been code changes in that area since
> march, I haven't checked).  WRT the Subject of this thread, I'd say
> definitely a bug.

Well, getting a backtrace produced:

#0  PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
#1  font_clear_cache (cache=15546662, driver=driver@entry=0xb7b6e0, f=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at font.c:2607

It looks like the `font_clear_cache` function was last modified by
Dmitry on 3 March, git commit b0c9db81.

i tried `next`ing through that function for a while[1], and at one point
started getting values for the `entity' variable such as -16777216 and
16777215, which look suspiciously like a 24-bit-related issue to this
untrained eye .... The last value of the `entity` variable i got before
the segfault was 536871013.

Does anyone have any advice as to how i can proceed further?


Alexis.

[1] Not fully, because i didn't know the value of `ASIZE (elt)`, since
according to GDB it had been optimized out, despite me `make`ing the
binary with `-O0 -g3`, as per etc/DEBUG (i'm running gcc 4.7.2).

Re: Emacs daemon segfaults [was: Possible bug when running with --daemon on 24.3.92.3?]

[Dmitry Antipov]

On 07/11/2014 08:51 AM, Alexis wrote:

> Well, getting a backtrace produced:
>
> #0  PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
> #1  font_clear_cache (cache=15546662, driver=driver@entry=0xb7b6e0, f=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at font.c:2607

Please send the backtrace with all stack frames.

Also note that original recipe, i.e.

1. emacs -q --daemon
2. emacsclient -c
3. C-x C-c
4. The `emacs --daemon` process is no longer running.

doesn't work for me (daemon is still alive after closing the frame).

Dmitry

Re: Emacs daemon segfaults [was: Possible bug when running with --daemon on 24.3.92.3?]

[Peder O. Klingenberg]

On Fri, Jul 11 2014 at 06:51, Alexis wrote:

> Well, getting a backtrace produced:
>
> #0  PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
> #1  font_clear_cache (cache=15546662, driver=driver@entry=0xb7b6e0, f=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at font.c:2607

That seems to be in the same general area as my bug.  Maybe try the
patch that I had success with?  Attached to comment #32 on the bug:

<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17125#32>

Adding your findings to that bug may also be worth while.

...Peder...
-- 
I wish a new life awaited _me_ in some off-world colony.

Re: Emacs daemon segfaults [was: Possible bug when running with --daemon on 24.3.92.3?]

[Alexis]

Dmitry Antipov writes:

> On 07/11/2014 08:51 AM, Alexis wrote:
>
>> Well, getting a backtrace produced:
>>
>> #0  PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
>> #1  font_clear_cache (cache=15546662, driver=driver@entry=0xb7b6e0, f=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at font.c:2607
>
> Please send the backtrace with all stack frames.

Program received signal SIGSEGV, Segmentation fault.
PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
2436          return PSEUDOVECTOR_TYPEP (h, code);
(gdb) backtrace
#0  PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
#1  font_clear_cache (cache=15546662, driver=driver@entry=0xb7b6e0, f=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at font.c:2607
#2  0x000000000056f990 in font_finish_cache (driver=0xb7b6e0, f=0x119d858) at font.c:2566
#3  font_update_drivers (f=f@entry=0x119d858, new_drivers=12100466) at font.c:3475
#4  0x0000000000426d84 in delete_frame (frame=<optimized out>, force=12100466) at frame.c:1335
#5  0x000000000055c338 in Ffuncall (nargs=<optimized out>, args=<optimized out>) at eval.c:2818
#6  0x000000000059077d in exec_byte_code (bytestr=5, vector=12039904, maxdepth=4611686018679046144, args_template=2052, nargs=142, args=0x2) at bytecode.c:916
#7  0x000000000055be57 in funcall_lambda (fun=140735955395408, nargs=nargs@entry=1, arg_vector=0x10ac1d0, arg_vector@entry=0x7fffa4a0e4a8) at eval.c:2983
#8  0x000000000055c123 in Ffuncall (nargs=2, args=0x7fffa4a0e4a0) at eval.c:2876
#9  0x000000000059077d in exec_byte_code (bytestr=5, vector=12039904, maxdepth=4611686018679046144, args_template=1028, nargs=63, args=0x2) at bytecode.c:916
#10 0x000000000055be57 in funcall_lambda (fun=140735955395744, nargs=nargs@entry=1, arg_vector=0x10ba390, arg_vector@entry=0x7fffa4a0e5d8) at eval.c:2983
#11 0x000000000055c123 in Ffuncall (nargs=2, args=0x7fffa4a0e5d0) at eval.c:2876
#12 0x000000000059077d in exec_byte_code (bytestr=5, vector=12039904, maxdepth=4611686018679046144, args_template=1024, nargs=11, args=0x2) at bytecode.c:916
#13 0x000000000055be57 in funcall_lambda (fun=140735955396048, nargs=nargs@entry=1, arg_vector=0x8adf30, arg_vector@entry=0x7fffa4a0e728) at eval.c:2983
#14 0x000000000055c123 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffa4a0e720) at eval.c:2876
#15 0x00000000005586dd in Fcall_interactively (function=16364402, record_flag=12100466, keys=12135165) at callint.c:836
#16 0x000000000055c328 in Ffuncall (nargs=<optimized out>, args=<optimized out>) at eval.c:2822
#17 0x000000000059077d in exec_byte_code (bytestr=5, vector=12039904, maxdepth=4611686018679046144, args_template=4100, nargs=108, args=0x4) at bytecode.c:916
#18 0x000000000055be57 in funcall_lambda (fun=140735955396808, nargs=nargs@entry=1, arg_vector=0x91c330, arg_vector@entry=0x7fffa4a0e9e8) at eval.c:2983
#19 0x000000000055c123 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x7fffa4a0e9e0) at eval.c:2876
#20 0x000000000055c4fa in call1 (fn=<optimized out>, arg1=<optimized out>) at eval.c:2614
#21 0x00000000004f6f2e in command_loop_1 () at keyboard.c:1559
#22 0x000000000055a6d5 in internal_condition_case (bfun=bfun@entry=0x4f6ba0 <command_loop_1>, handlers=<optimized out>, hfun=hfun@entry=0x4edc70 <cmd_error>) at eval.c:1354
#23 0x00000000004eb76e in command_loop_2 (ignore=ignore@entry=12100466) at keyboard.c:1177
#24 0x000000000055a5db in internal_catch (tag=12147682, func=func@entry=0x4eb750 <command_loop_2>, arg=12100466) at eval.c:1118
#25 0x00000000004ed877 in command_loop () at keyboard.c:1156
#26 recursive_edit_1 () at keyboard.c:777
#27 0x00000000004edb8d in Frecursive_edit () at keyboard.c:848
#28 0x00000000004196c5 in main (argc=3, argv=<optimized out>) at emacs.c:1646

Lisp Backtrace:
"delete-frame" (0xa4a0e358)
"server-delete-client" (0xa4a0e4a8)
"server-save-buffers-kill-terminal" (0xa4a0e5d8)
"save-buffers-kill-terminal" (0xa4a0e728)
"call-interactively" (0xa4a0e8d0)
"command-execute" (0xa4a0e9e8)

> Also note that original recipe, i.e.
>
> 1. emacs -q --daemon
> 2. emacsclient -c
> 3. C-x C-c
> 4. The `emacs --daemon` process is no longer running.
>
> doesn't work for me (daemon is still alive after closing the frame).

*nod* This issue has only appeared for me on 64-bit Debian Wheezy, not
on the 32-bit version.


Alexis.

Re: Emacs daemon segfaults [was: Possible bug when running with --daemon on 24.3.92.3?]

[Alexis]

Peder O. Klingenberg writes:

> On Fri, Jul 11 2014 at 06:51, Alexis wrote:
>
>> Well, getting a backtrace produced:
>>
>> #0  PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
>> #1  font_clear_cache (cache=15546662, driver=driver@entry=0xb7b6e0, f=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at font.c:2607
>
> That seems to be in the same general area as my bug.  Maybe try the
> patch that I had success with?  Attached to comment #32 on the bug:
>
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17125#32>
>
> Adding your findings to that bug may also be worth while.

Yes, that patch fixed the issue; both C-x C-c and C-x 5 0 now close the
frame without shutting down the daemon. :-) Thanks!


Alexis.

Re: Emacs daemon segfaults [was: Possible bug when running with --daemon on 24.3.92.3?]

[Alexis]

Peder O. Klingenberg writes:

> On Fri, Jul 11 2014 at 06:51, Alexis wrote:
>
>> Well, getting a backtrace produced:
>>
>> #0  PSEUDOVECTORP (code=15, a=536871013) at lisp.h:2436
>> #1  font_clear_cache (cache=15546662, driver=driver@entry=0xb7b6e0, f=<error reading variable: Unhandled dwarf expression opcode 0xfa>) at font.c:2607
>
> That seems to be in the same general area as my bug.  Maybe try the
> patch that I had success with?  Attached to comment #32 on the bug:
>
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17125#32>
>
> Adding your findings to that bug may also be worth while.

i also just tried Dmitry's fixed_3.patch:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17125#38

which also worked.

i'll add a new comment on that bug. Thanks again!


Alexis.