GNU bug report logs - #17125
24.4.50; daemon mode: closing X client frame exits entire emacs

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17125 in the body.
You can then email your comments to 17125 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: peder <at> klingenberg.no (Peder O. Klingenberg)
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; daemon mode: closing X client frame exits entire emacs
Date: Thu, 27 Mar 2014 23:47:40 +0100

Emacs compiled from git sources pulled 2014-03-26.  I have a tiny local
patch to startup.el that loads debian-startup in addition to the normal
site-run-file (as long as site-run-file is non-nil), otherwise the
sources are clean.  I ran autoreconf and configure, then built with
"make bootstrap".

This triggers the behaviour:

$ emacs -no-site-file -no-init-file --daemon=test
$ emacsclient -nc -s test

In emacs frame: C-x 5 0

The minibuffer flashes "No files need saving", the frame closes, and the
emacs process is gone.  Subsequent emacsclient invocations naturally
fail with the messages

emacsclient: connect: Connection refused
emacsclient: error accessing socket "test"

This does _not_ trigger the behaviour:

$ emacs -no-site-file -no-init-file --daemon=test
$ emacsclient -t -s test

In emacs frame: C-x 5 0

The terminal frame exits, but I can reconnect again with another
emacsclient call.

Another way of _not_ triggering it:

$ emacs -Q --daemon=test
$ emacsclient -nc -s test

Again I can exit the frame with C-x 5 0 and immediately reconnect, as
expected.

The only difference I could find between "-Q" and "-no-site-file
-no-init-file" was that "-Q" sets inhibit-x-resources to t in
startup.el.  This sort of ties in to the problem only showing up when I
start X frames, but I am at a loss as to how to dig deeper.

I have some ancient X resources influencing emacs, but I fail to see how
they can have an impact.  Here's the output of "xrdb -query | grep -i
emacs":
Emacs*background:	black
Emacs*cursorColor:	SeaGreen
Emacs*font:	7x13
Emacs*foreground:	DarkSeaGreen
Emacs*menubar.background:	Black
Emacs*menubar.bottomShadowColor:	DimGray
Emacs*menubar.font:	-*-fixed-bold-r-normal--13-*-*-*-*-70-iso8859-1
Emacs*menubar.foreground:	DarkSeaGreen
Emacs*menubar.margin:	0
Emacs*menubar.topShadowColor:	DarkGray
Emacs*pointerColor:	SlateGrey
Emacs*popup.font:	-*-fixed-bold-r-normal--13-*-*-*-*-70-iso8859-1
Emacs*shadowThickness:	1
Emacs*verticalScrollBars.background:	Black
Emacs*verticalScrollBars.foreground:	DarkSeaGreen
Emacs.geometry:	85x75+0+0

Does any of this ring a bell for someone?  Any ideas for where I should
be looking?  Any more relevant info I should provide?





In GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2014-03-26 on luna
Windowing system distributor `The X.Org Foundation', version 11.0.10402000
System Description:	Ubuntu 10.04.4 LTS

Configured using:
 `configure --prefix=/usr/local/emacs-git
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.0.92/site-lisp:/usr/local/share/emacs/site-lisp/:/usr/share/emacs/24.0.92/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=lucid --with-toolkit-scroll-bars
 --with-pop=yes'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r SPC e m <tab> <return>

Recent messages:
Starting Emacs daemon.
When done with this frame, type C-x 5 0

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message idna dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util help-fns mail-prsvr mail-utils server time-date
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list
newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp
files text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty emacs)

Memory information:
((conses 16 77836 8053)
 (symbols 48 17986 0)
 (miscs 40 45 113)
 (strings 32 11943 4704)
 (string-bytes 1 319662)
 (vectors 16 10109)
 (vector-slots 8 382979 8265)
 (floats 8 71 60)
 (intervals 56 202 0)
 (buffers 960 12)
 (heap 1024 23942 627))

Message #8 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: peder <at> klingenberg.no (Peder O. Klingenberg)
To: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: Acknowledgement (24.4.50;
 daemon mode: closing X client frame exits entire emacs)
Date: Tue, 01 Apr 2014 13:35:24 +0200

The server process exits with a SIGSEGV and a core dump.  The error
seems to happen in font_clear_cache, maybe related to the changes
described in bug #16069

Attaching a gdb to the server process before starting the emacsclient
allowed me to capture the following:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000535f4e in PSEUDOVECTOR_TYPEP (a=0x7469672d73636168, code=15) at lisp.h:2378
2378      return ((a->size & (PSEUDOVECTOR_FLAG | PVEC_TYPE_MASK))
(gdb) bt full
#0  0x0000000000535f4e in PSEUDOVECTOR_TYPEP (a=0x7469672d73636168, code=15) at lisp.h:2378
No locals.
#1  0x0000000000535fbe in PSEUDOVECTORP (a=8388349225861341549, code=15) at lisp.h:2392
        h = 0x7469672d73636168
#2  0x00000000005e528d in font_clear_cache (f=0x1244b48, cache=16218886, driver=0xc219c0) at font.c:2604
        tail = 16211750
        elt = 12770162
        entity = 8388349225861341549
        i = 2175
#3  0x00000000005e5111 in font_finish_cache (f=0x1244b48, driver=0xc219c0) at font.c:2563
        cache = 16217926
        val = 16218726
        tmp = 16218902
#4  0x00000000005e7c87 in font_update_drivers (f=0x1244b48, new_drivers=12770162) at font.c:3472
        driver = 0xc219c0
        active_drivers = 12770162
        list = 0xece050
#5  0x0000000000423a92 in delete_frame (frame=19155789, force=12770162) at frame.c:1335
        f = 0x1244b48
        sf = 0xc41808
        kb = 0xc2db72
        minibuffer_selected = 0
        is_tooltip_frame = 0
#6  0x0000000000423fb7 in Fdelete_frame (frame=12770162, force=12770162) at frame.c:1509
No locals.
#7  0x00000000005d015d in Ffuncall (nargs=1, args=0x7fff937ae7a0) at eval.c:2818
        fun = 9305797
        original_fun = 12813026
        funcar = 140735667693392
        numargs = 0
        lisp_numargs = 2474305360
        val = 6099069
        internal_args = 0x7fff937ae6d0
        i = 2
#8  0x00000000005ca955 in Fcall_interactively (function=12813026, record_flag=12770162, keys=12804829) at callint.c:836
        val = 42949672960
        args = 0x7fff937ae7a0
        visargs = 0x7fff937ae780
        specs = 9339777
        filter_specs = 9339777
        teml = 42958978752
        up_event = 12770162
        enable = 12770162
        speccount = 5
        next_event = 3
        prefix_arg = 12770162
        string = 0x7fff937ae7c0 ""
        tem = 0x7fff937ae7c0 ""
        varies = 0x7fff937ae770 ""
        i = 1
        nargs = 1
        mark = 5463998
        arg_from_tty = false
        gcpro1 = {
          next = 0x0, 
          var = 0xa9c85d, 
          nvars = 140735667693744
        }
        gcpro2 = {
          next = 0x8, 
          var = 0xa9c8ad, 
          nvars = 140735667693792
        }
        gcpro3 = {
          next = 0x87, 
          var = 0xe06d9a47a6aa0200, 
          nvars = 1
        }
        gcpro4 = {
          next = 0x6, 
          var = 0x7fff937ae848, 
          nvars = 1
        }
        gcpro5 = {
          next = 0x7fff937ae460, 
          var = 0x0, 
          nvars = 11126960
        }
        key_count = 3
        record_then_fail = false
        save_this_command = 12813026
        save_last_command = 20548306
        save_this_original_command = 12813026
        save_real_this_command = 12813026
#9  0x00000000005d0190 in Ffuncall (nargs=4, args=0x7fff937aea98) at eval.c:2822
        fun = 12199085
        original_fun = 12946690
        funcar = 13065590
        numargs = 3
        lisp_numargs = 12809906
        val = 12770162
        internal_args = 0x7fff937aeaa0
        i = 2
#10 0x0000000000610808 in exec_byte_code (bytestr=10260337, vector=10260373, maxdepth=52, args_template=4100, nargs=1, args=0x7fff937af000) at bytecode.c:919
        targets = {0x613e3e, 0x613e9b, 0x613e9d, 0x613e9f, 0x613ea1, 0x613ea1, 0x613eff, 0x613f70, 0x6100dc, 0x6100de, 0x6100e0, 0x6100e2, 0x6100e4, 0x6100e4, 0x6100ea, 
          0x6100a1, 0x61052a, 0x61052c, 0x61052e, 0x610530, 0x610532, 0x610532, 0x610573, 0x610538, 0x610719, 0x61071b, 0x61071d, 0x61071f, 0x610721, 0x610721, 
          0x6106c1, 0x6106de, 0x6107d5, 0x6107d7, 0x6107d9, 0x6107db, 0x6107dd, 0x6107dd, 0x61077d, 0x61079a, 0x610898, 0x61089a, 0x61089c, 0x61089e, 0x6108a0, 
          0x6108a0, 0x610840, 0x61085d, 0x611905, 0x611632, 0x611629, 0x613e3e, 0x613e3e, 0x613e3e, 0x613e3e, 0x613e3e, 0x611b24, 0x611c0c, 0x611c63, 0x611cba, 
          0x611d15, 0x6103bc, 0x610427, 0x611d7f, 0x61031e, 0x61048b, 0x611dda, 0x611e3e, 0x611e85, 0x611ee9, 0x611f37, 0x612007, 0x61204e, 0x6120b2, 0x612130, 
          0x612177, 0x6121be, 0x612222, 0x612286, 0x6122ea, 0x612368, 0x6123b6, 0x612404, 0x6124d4, 0x612561, 0x6125ee, 0x61282a, 0x612893, 0x6128fc, 0x612965, 
          0x6129ce, 0x612a1c, 0x612aaa, 0x612af8, 0x612b46, 0x612b94, 0x612c94, 0x6114c2, 0x612cf5, 0x612d3c, 0x612e07, 0x612e68, 0x612ec9, 0x612f10, 0x612f60, 
          0x612fb0, 0x613008, 0x613e3e, 0x613059, 0x61309b, 0x6130dd, 0x61311f, 0x613161, 0x6131a3, 0x6114c2, 0x613e3e, 0x6131ea, 0x613239, 0x613280, 0x6132c7, 
          0x61332b, 0x61338f, 0x6133d6, 0x6134af, 0x613513, 0x613577, 0x6135db, 0x61361d, 0x613e3e, 0x6113fb, 0x61093c, 0x6101db, 0x610a58, 0x610b9b, 0x610cd5, 
          0x61138e, 0x6113c5, 0x61066f, 0x61147f, 0x6114f8, 0x611580, 0x6115c3, 0x611948, 0x6119c5, 0x611a43, 0x611aa8, 0x6108f5, 0x613664, 0x6136e2, 0x613729, 
          0x613770, 0x6137b7, 0x6137fe, 0x613862, 0x6138c6, 0x61392a, 0x61398e, 0x613abe, 0x613b22, 0x613b86, 0x613bcd, 0x613c31, 0x613c95, 0x613cea, 0x613d3f, 
          0x612be2, 0x612c30, 0x613d8d, 0x613de8, 0x613e3e, 0x610e0f, 0x610efe, 0x611026, 0x61114e, 0x61126e, 0x611f85, 0x612452, 0x612d85, 0x614005, 0x614076, 
          0x613e3e, 0x613e3e, 0x61410b, 0x613e3e, 0x613e3e, 0x613e3e, 0x613e3e, 0x613e3e, 0x613e3e, 0x613e3e, 0x613e3e, 0x613e3e, 0x614190 <repeats 64 times>}
        count = 4
        count_volatile = 51546406209
        op = 3
        vectorp = 0x9c8f98
        vectorp_volatile = 0x62a808
        stack = {
          pc = 0xb4c0a3 "\006\006\071\203\225", 
          byte_string = 10260337, 
          byte_string_start = 0xb4c035 "\305\020\211?\205\f", 
          next = 0x0
        }
        stack_volatile = {
          pc = 0x100c342f0 <Address 0x100c342f0 out of bounds>, 
          byte_string = 12796416, 
          byte_string_start = 0xc36ef2 "", 
          next = 0x130b796
        }
        top = 0x7fff937aea98
        result = 849472764
        type = 12
#11 0x00000000005d086f in funcall_lambda (fun=10260293, nargs=1, arg_vector=0x7fff937aeff8) at eval.c:2983
        val = 10260293
        syms_left = 4100
        next = 5463998
        lexenv = 140735667695384
        count = 4
        i = 51546072263
        optional = false
        rest = false
#12 0x00000000005d033c in Ffuncall (nargs=2, args=0x7fff937aeff0) at eval.c:2864
        fun = 10260293
        original_fun = 12813698
        funcar = 12619168
        numargs = 1
        lisp_numargs = 5
        val = 2
        internal_args = 0x7fff937af498
        i = 12770162
#13 0x00000000005cfae6 in call1 (fn=12813698, arg1=12813026) at eval.c:2614
        ret_ungc_val = 12770162
        gcpro1 = {
          next = 0x1, 
          var = 0x1301966, 
          nvars = 2
        }
        args = {12813698, 12813026}
#14 0x000000000053cee7 in command_loop_1 () at keyboard.c:1556
        scount = 2
        cmd = 12813026
        keybuf = {96, 212, 192, 5981058, 12619328, 12770162, 5463863, 12770162, 140735667695808, 5983251, 12770162, 12934418, 140735667695888, 5982183, 12619328, 
          12770162, 12934416, 20878576, 140735667695952, 6099650, 13053686, 2, 5, 12934416, 12619328, 140735667695888, 12770162, 17072050, 13053686, 9905253}
        i = 3
        prev_modiff = 11
        prev_buffer = 0xc342f0
        already_adjusted = false
#15 0x00000000005ccf95 in internal_condition_case (bfun=0x53c7f5 <command_loop_1>, handlers=12821410, hfun=0x53c0f8 <cmd_error>) at eval.c:1354
        val = 64
        c = 0x13dda30
#16 0x000000000053c54f in command_loop_2 (ignore=12770162) at keyboard.c:1174
        val = 140735667696792
#17 0x00000000005cc788 in internal_catch (tag=12817346, func=0x53c529 <command_loop_2>, arg=12770162) at eval.c:1118
        val = 12770162
        c = 0x13dd900
#18 0x000000000053c501 in command_loop () at keyboard.c:1153
No locals.
#19 0x000000000053bcf3 in recursive_edit_1 () at keyboard.c:777
        count = 1
        val = 12770162
#20 0x000000000053be60 in Frecursive_edit () at keyboard.c:845
        count = 0
        buffer = 12770162
#21 0x0000000000539f04 in main (argc=4, argv=0x7fff937af498) at emacs.c:1654
        dummy = 140285200712912
        stack_bottom_variable = 0 '\000'
        do_initial_setlocale = true
        dumping = false
        skip_args = 1
        rlim = {
          rlim_cur = 8720000, 
          rlim_max = 18446744073709551615
        }
        no_loadup = false
        junk = 0x0
        dname_arg = 0x7fff937b0870 "test"
        ch_to_dir = 0x689070 "H\211l$\330L\211d$\340H\215-\323J%"
        original_pwd = 0x0

Lisp Backtrace:
"delete-frame" (0x937ae7a8)
"call-interactively" (0x937aeaa0)
"command-execute" (0x937aeff8)


I poked around at different stuff, and this seemed somehow relevant:

(gdb) f 2
#2  0x00000000005e528d in font_clear_cache (f=0x1244b48, cache=16218886, driver=0xc219c0) at font.c:2604
2604                  if (FONT_ENTITY_P (entity)
(gdb) p elt
$14 = 12770162
(gdb) xpr
Lisp_Symbol
$15 = (struct Lisp_Symbol *) 0xc2db70
"nil"


I also evaluated (frame-font-cache) in both the error case and when I
started started the server with -Q (which, if you recall, means emacs
does not segfault at the first delete-frame).

-Q:
(frame-font-cache)
(":0" (x 1) (xft 1))

--no-site-file --no-init-file:
(frame-font-cache)
(":0" (x 1 (#<font-spec x misc fixed ## iso8859-1 nil nil nil nil nil 110 nil ((user-spec . "7x13"))> . [#<font-entity x misc fixed ## iso8859-1 medium r semicondensed 13 75 110 60 nil> #<font-entity x misc fixed ## iso8859-1 medium r semicondensed 13 100 110 60 nil> #<font-entity x misc fixed ## iso8859-1 medium r semicondensed 12 100 110 60 nil> #<font-entity x misc fixed ## iso8859-1 medium r semicondensed 12 75 110 60 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 9 75 110 60 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 9 100 110 60 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 8 75 110 50 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 8 100 110 50 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 7 75 110 50 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 7 100 110 50 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 6 75 110 40 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 20 75 110 100 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 20 100 110 100 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 18 100 110 90 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 15 75 110 90 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 15 100 110 90 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 14 75 110 70 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 14 100 110 70 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 13 75 110 80 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 13 75 110 70 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 13 100 110 80 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 13 100 110 70 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 10 100 110 60 nil> #<font-entity x misc fixed ## iso8859-1 medium r normal 10 75 110 60 nil> #<font-entity x misc fixed ## iso8859-1 medium o semicondensed 13 75 110 60 nil> #<font-entity x misc fixed ## iso8859-1 medium o normal 13 75 110 80 nil> #<font-entity x misc fixed ## iso8859-1 medium o normal 13 75 110 70 nil> #<font-entity x misc fixed ## iso8859-1 bold r semicondensed 13 75 110 60 nil> #<font-entity x misc fixed ## iso8859-1 bold r semicondensed 13 100 110 60 nil> #<font-entity x misc fixed ## iso8859-1 bold r normal 18 100 110 90 nil> #<font-entity x misc fixed ## iso8859-1 bold r normal 15 75 110 90 nil> #<font-entity x misc fixed ## iso8859-1 bold r normal 15 100 110 90 nil> #<font-entity x misc fixed ## iso8859-1 bold r normal 14 75 110 70 nil> #<font-entity x misc fixed ## iso8859-1 bold r normal 13 75 110 80 nil> #<font-entity x misc fixed ## iso8859-1 bold r normal 13 75 110 70 nil> #<font-entity x misc fixed ## iso8859-1 bold r normal 13 100 110 80 nil> #<font-entity x misc fixed ## iso8859-1 bold r normal 13 100 110 70 nil>]) (#<font-spec x nil 7x13 nil nil normal normal normal nil nil nil nil ((:name . "7x13"))> . #<font-entity x Misc Fixed ## ISO8859-1 medium r normal 13 75 110 70 nil>)) (xft 1 (#<font-spec xft misc fixed ## iso8859-1 nil nil nil nil nil 110 nil ((user-spec . "7x13"))> . []) (#<font-spec xft nil 7x13 nil nil normal normal normal nil nil nil nil ((:name . "7x13"))>) (#<font-spec xft nil Monospace nil iso8859-1 nil nil nil nil nil nil nil ((:name . "Monospace 10"))> . [#<font-entity xft bitstream Bitstream\ Vera\ Sans\ Mono nil iso10646-1 bold oblique normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBI.ttf" . 0) (:name . "Monospace 10"))> #<font-entity xft bitstream Bitstream\ Vera\ Sans\ Mono nil iso10646-1 normal normal normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMono.ttf" . 0) (:name . "Monospace 10"))> #<font-entity xft bitstream Bitstream\ Vera\ Sans\ Mono nil iso10646-1 normal oblique normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoIt.ttf" . 0) (:name . "Monospace 10"))> #<font-entity xft bitstream Bitstream\ Vera\ Sans\ Mono nil iso10646-1 bold normal normal 0 nil 100 0 ((:font-entity "/usr/share/fonts/truetype/ttf-bitstream-vera/VeraMoBd.ttf" . 0) (:name . "Monospace 10"))>])))

Looking at the local i in stack frame #2 above, it seems way out of
bounds at 2175.

Message #11 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: "Peder O. Klingenberg" <peder <at> klingenberg.no>
Cc: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client
 frame exits entire emacs)
Date: Tue, 01 Apr 2014 17:47:38 +0400

On 04/01/2014 03:35 PM, Peder O. Klingenberg wrote:

> The server process exits with a SIGSEGV and a core dump.  The error
> seems to happen in font_clear_cache, maybe related to the changes
> described in bug #16069
>
> Attaching a gdb to the server process before starting the emacsclient
> allowed me to capture the following:

Could you also try to install a breakpoint at font.c:2600 and then call
debug_print (elt) when hit? Probably elt is bogus here (not a vector).
Also please recompile with --enable-checking to get easserts into the game.

Dmitry

Message #14 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: peder <at> klingenberg.no (Peder O. Klingenberg)
To: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: Acknowledgement (24.4.50;
 daemon mode: closing X client frame exits entire emacs)
Date: Tue, 01 Apr 2014 16:09:36 +0200

Dmitry Antipov <dmantipov <at> yandex.ru> writes:

> Could you also try to install a breakpoint at font.c:2600 and then call
> debug_print (elt) when hit? Probably elt is bogus here (not a vector).
> Also please recompile with --enable-checking to get easserts into the game.

I found and defined ENABLE_CHECKING in config.h before seeing your
reply.  The eassert does indeed trigger.  Changing "eassert" to "if"
makes the segfault go away, and I can start clients to my heart's
content.  The value of (frame-font-cache) on the lisp side is reduced
when reattaching the second (and subsequent) clients, to only

(":0" (x 1 (#<font-spec x nil 7x13 nil nil normal normal normal nil nil nil nil ((:name . "7x13"))> . #<font-entity x Misc Fixed ## ISO8859-1 medium r normal 13 75 110 70 nil>)) (xft 1 (#<font-spec xft nil 7x13 nil nil normal normal normal nil nil nil nil ((:name . "7x13"))>)))

I will do the breakpoint thing, but I'm out of time at the moment.  I'll
get to it either later today or tomorrow.

Thanks!

--
...Peder...

Message #17 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: "Peder O. Klingenberg" <peder <at> klingenberg.no>
Cc: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client
 frame exits entire emacs)
Date: Tue, 01 Apr 2014 19:08:40 +0400

[Message part 1 (text/plain, inline)]

On 04/01/2014 06:09 PM, Peder O. Klingenberg wrote:

> I will do the breakpoint thing, but I'm out of time at the moment.  I'll
> get to it either later today or tomorrow.

Don't; please try this patch instead (hopefully it fixes a bug
in font_matching_entity).

Dmitry

[bug17125.patch (text/x-patch, attachment)]

Message #20 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> suse.de>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: "Peder O. Klingenberg" <peder <at> klingenberg.no>, 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: Acknowledgement (24.4.50;
 daemon mode: closing X client frame exits entire emacs)
Date: Tue, 01 Apr 2014 17:27:09 +0200

Dmitry Antipov <dmantipov <at> yandex.ru> writes:

> === modified file 'src/lisp.h'
> --- src/lisp.h	2014-03-27 22:52:14 +0000
> +++ src/lisp.h	2014-04-01 14:07:02 +0000
> @@ -3709,6 +3709,16 @@
>    return v;
>  }
>  
> +/* Fast path to avoid Fvconcat (1, &obj).  */
> +
> +INLINE Lisp_Object
> +vector1 (Lisp_Object obj)
> +{
> +  Lisp_Object v = make_uninit_vector (1);
> +  ASET (v, 0, obj);
> +  return v;
> +}
> +

This is not a useful comment.  Fvconcat(1,&obj) and vector1(obj) have
quite different semantics.  The latter creates a one-element vector
containing obj (same as Fvector(1,&obj)), whereas the former creates a
vector from all elements in obj.

Andreas.

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

Message #23 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Andreas Schwab <schwab <at> suse.de>
Cc: "Peder O. Klingenberg" <peder <at> klingenberg.no>, 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client
 frame exits entire emacs)
Date: Tue, 01 Apr 2014 20:27:44 +0400

[Message part 1 (text/plain, inline)]

On 04/01/2014 07:27 PM, Andreas Schwab wrote:

> This is not a useful comment.  Fvconcat(1,&obj) and vector1(obj) have
> quite different semantics.  The latter creates a one-element vector
> containing obj (same as Fvector(1,&obj)), whereas the former creates a
> vector from all elements in obj.

Argh, that was a horrible mistake. Thanks.

Peder, please try this instead.

Dmitry

[bug17125_fixed.patch (text/x-patch, attachment)]

Message #26 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: "Peder O. Klingenberg" <peder <at> klingenberg.no>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Andreas Schwab <schwab <at> suse.de>, 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: Acknowledgement (24.4.50;
 daemon mode: closing X client frame exits entire emacs)
Date: Tue, 1 Apr 2014 23:02:08 +0200

On 1 Apr, 2014, at 18:27, Dmitry Antipov <dmantipov <at> yandex.ru> wrote:

> Peder, please try this instead.
[...]
> <bug17125_fixed.patch>

I skipped your earlier patch, and applied this one on top of a clean font.c, reverting my own experiments.

It was not an unconditional success, unfortunately.  Nothing segfaults anymore, but now I’m not able to attach a graphical emacsclient at all:

$ emacsclient -nc -s test
*ERROR*: Wrong type argument: font, []

Until now I’ve been using emacsclient as built with the clean 24.4.50 sources.  I tried with a post-patch build of emacsclient as well, no difference.  Neither gdb on the server process or gdb on the emacsclient invocation caught a signal.

So I set up a terminal client, set debug-on-error and debug-on-quit and debug-on-signal all to t (they were the ones I could remember…)
When I ran “emacsclient -nc -s test” I got the following backtrace (deeper frames and irrelevant environment elided):

Debugger entered--Lisp error: (wrong-type-argument font [])
  x-create-frame(((visibility) (height . 75) (width . 85) (display . "localhost:11.0") (client . nowait) (environment "...")))
  x-create-frame-with-faces(((height . 75) (width . 85) (display . "localhost:11.0") (client . nowait) (environment "..."))
  make-frame(((display . "localhost:11.0") (client . nowait) (environment "..."))
  make-frame-on-display("localhost:11.0" ((client . nowait) (environment "..."))
  server-create-window-system-frame("localhost:11.0" t #<process test <6>> nil nil)
[…]

-- 
...Peder...

Message #29 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: "Peder O. Klingenberg" <peder <at> klingenberg.no>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Andreas Schwab <schwab <at> suse.de>, 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: 24.4.50;
 daemon mode: closing X client frame exits entire emacs
Date: Wed, 2 Apr 2014 00:07:30 +0200

On 1 Apr, 2014, at 23:02, Peder O. Klingenberg <peder <at> klingenberg.no> wrote:

>  x-create-frame(((visibility) (height . 75) (width . 85) (display . "localhost:11.0") (client . nowait) (environment "...")))

Stepping through this function in gdb, the trace seems to be

x-create-frame calls 
x_default_font_parameter (xfns.c:3049) calls
x_default_parameter (xfns.c:2832) calls
x_set_frame_parameters (frame.c:4018)

bt full from a breakpoint on frame.c:4018 shows (top only, it’s 48 frames down to main().  Let me know if there may be interesting stuff there)

(gdb) bt full
#0  x_default_parameter (f=0x135d9e0, alist=17834182, prop=14078850, deflt=16340481, xprop=0x6eba5e "font", xclass=0x6eba59 "Font", 
    type=RES_TYPE_STRING) at frame.c:4018
        tem = 16340577
#1  0x0000000000543a60 in x_default_font_parameter (f=0x135d9e0, parms=17834182) at xfns.c:2832
        dpyinfo = 0x1a64170
        font_param = 13859698
        font = 16340481
#2  0x0000000000544577 in Fx_create_frame (parms=17834182) at xfns.c:3049
        f = 0x135d9e0
        frame = 20306405
        tem = 13859650
        name = 13859650
        minibuffer_only = 0
        window_prompting = 0
        width = 5642964
        height = 32767
        count = 31
        gcpro1 = {
          next = 0x87, 
          var = 0x975b4384e3bea600, 
          nvars = 140733812145632
        }
        gcpro2 = {
          next = 0x21, 
          var = 0x7fff24e17dc8, 
          nvars = 5649570
        }
        gcpro3 = {
          next = 0x7fff24e179c8, 
          var = 0x0, 
          nvars = 9956832
        }
        gcpro4 = {
          next = 0x2, 
          var = 0x2, 
          nvars = 514
        }
        display = 16339697
        dpyinfo = 0x1a64170
        parent = 13859698
        kb = 0x14f8b80

This may be relevant:

(gdb) f  1
#1  0x0000000000543a60 in x_default_font_parameter (f=0x135d9e0, parms=17834182) at xfns.c:2832
2832	  x_default_parameter (f, parms, Qfont, font, "font", "Font", RES_TYPE_STRING);
(gdb) p font
$1 = 16340481
(gdb) xpr
Lisp_String
$2 = (struct Lisp_String *) 0xf95600
"7x13"
(gdb) p font_param
$3 = 13859698
(gdb) xpr
Lisp_Symbol
$4 = (struct Lisp_Symbol *) 0xd37b70
"nil"


-- 
...Peder...

Message #32 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: "Peder O. Klingenberg" <peder <at> klingenberg.no>
Cc: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client
 frame exits entire emacs)
Date: Wed, 02 Apr 2014 07:46:19 +0400

[Message part 1 (text/plain, inline)]

On 04/02/2014 01:02 AM, Peder O. Klingenberg wrote:

> I skipped your earlier patch, and applied this one on top of a clean font.c, reverting my own experiments.
>
> It was not an unconditional success, unfortunately.  Nothing segfaults anymore, but now I’m not able to attach a graphical emacsclient at all:
>
> $ emacsclient -nc -s test
> *ERROR*: Wrong type argument: font, []

Hm...should we avoid empty vectors in font cache entities? Try this.

Dmitry

[bug17125_fixed_2.patch (text/x-patch, attachment)]

Message #35 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: peder <at> klingenberg.no (Peder O. Klingenberg)
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: 24.4.50;
 daemon mode: closing X client frame exits entire emacs
Date: Wed, 02 Apr 2014 13:50:24 +0200

Dmitry Antipov <dmantipov <at> yandex.ru> writes:

> Hm...should we avoid empty vectors in font cache entities? Try this.

Success!

Reverting bug17125_fixed.patch and applying your bug17125_fixed_2.patch,
I have an emacs running in daemon mode which does not segfault anymore.

Thanks!  This bug was really messing up my workflow.

-- 
...Peder...

Message #38 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: "Peder O. Klingenberg" <peder <at> klingenberg.no>
Cc: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: 24.4.50; daemon mode: closing X client frame exits
 entire emacs
Date: Wed, 02 Apr 2014 16:24:05 +0400

[Message part 1 (text/plain, inline)]

On 04/02/2014 03:50 PM, Peder O. Klingenberg wrote:

> Success!
>
> Reverting bug17125_fixed.patch and applying your bug17125_fixed_2.patch,
> I have an emacs running in daemon mode which does not segfault anymore.
>
> Thanks!  This bug was really messing up my workflow.

This patch prevents [] (empty vector, means "no match") from entering font cache.
IMO this is correct, but this breaks current behavior of font_list_entities.
Could you please also try a more compatible/conservative change?

Dmitry

[bug17125_fixed_3.patch (text/x-patch, attachment)]

Message #41 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: peder <at> klingenberg.no (Peder O. Klingenberg)
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: 24.4.50;
 daemon mode: closing X client frame exits entire emacs
Date: Wed, 02 Apr 2014 15:01:43 +0200

Dmitry Antipov <dmantipov <at> yandex.ru> writes:

> This patch prevents [] (empty vector, means "no match") from entering font cache.
> IMO this is correct, but this breaks current behavior of font_list_entities.
> Could you please also try a more compatible/conservative change?

Sorry, this dies in the GC before any frame becomes visible:

(gdb) bt full
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:355
No locals.
#1  0x00000000005edad0 in die (
    msg=0x710f40 "FONT_ENTITY_P (AREF (((suppress_checking || ((((enum Lisp_Type) ((obj) & ~(1 ? - (1 << 3) : (9223372036854775807L >> (3 - 1))))) == Lisp_Cons)) ? (void) 0 : die (\"CONSP (obj)\", \"alloc.c\", 5374)), (str"..., file=0x7104c8 "alloc.c", line=5374)
    at alloc.c:6799
No locals.
#2  0x00000000005ea9b2 in compact_font_cache_entry (entry=17306966) at alloc.c:5374
        i = 0
        size = 1
        drop = false
        obj = 17300758
        tail = 17300742
        prev = 0x1081568
#3  0x00000000005eaba9 in compact_font_caches () at alloc.c:5407
        entry = 17306838
        cache = 18430694
        t = 0x110f6a0
#4  0x00000000005eb1eb in Fgarbage_collect () at alloc.c:5582
        nextb = 0x0
        stack_top_variable = 0 '\000'
        i = 1618
        message_p = false
        count = 40
        start = {
          tv_sec = 1396443207, 
          tv_nsec = 632197068
        }
        retval = 13859698
        tot_before = 0
[skipped 67 more frames, let me know if you want them.]

Lisp Backtrace:
"Automatic GC" (0xd2aba0)
"x-create-frame" (0x2034c850)
"x-create-frame-with-faces" (0x2034cd70)
"make-frame" (0x2034d290)
"make-frame-on-display" (0x2034d7e8)
"server-create-window-system-frame" (0x2034dd98)
0x120c6a8 PVEC_COMPILED
"funcall" (0x2034e310)
0x120bee8 PVEC_COMPILED
"funcall" (0x2034eac0)
"server-process-filter" (0x2034f1f8)


-- 
...Peder...

Message #44 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Alexis <flexibeast <at> gmail.com>
To: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: 24.4.50;
 daemon mode: closing X client frame exits entire emacs
Date: Fri, 11 Jul 2014 19:01:48 +1000

As per this discussion on the emacs-devel list:

https://lists.gnu.org/archive/html/emacs-devel/2014-07/msg00059.html

i was having similar problems, cf. this backtrace:

https://lists.gnu.org/archive/html/emacs-devel/2014-07/msg00130.html

However, applying either Dmitry's fixed_2.patch or fixed_3.patch solved
the problem for me; both C-x C-c and C-x 5 0 close the frame without
shutting down the daemon.


Alexis.

Message #47 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Alexis <flexibeast <at> gmail.com>
To: 18041 <at> debbugs.gnu.org
Cc: 17125 <at> debbugs.gnu.org
Subject: Re: bug#18041: 24.3; Exiting emacsclient kills emacs --daemon
Date: Fri, 18 Jul 2014 11:32:21 +1000

Perhaps related to bug #17125?

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


Alexis.

--

Mel Byrne writes:

> Running emacs 24.3.1 on Linux Mint 17 Cinnamon edition. I start an emacs
> daemon using
>
> $ emacs --daemon
>
> and connect to it using
>
> $ emacsclient -c
>
> I open 5 shell buffers called k0 and [0123]_idl. I run bash in k0 and an
> interactive IDL process in each of the ?_idl buffers. I start IDL
> number-crunching processes in each of the ?_idl buffers. I then ssh -X
> into the machine and run another emacsclient -c to give me access and
> control to the ?_idl processes. Exiting the emacsclient using either C-x
> C-c *or* C-x 5 0 kills the emacs 24.3.1 daemon.
>
> On my Linux Mint 13 MATE machine, I can run emacsclient against the
> emacs 23 daemon and exit using either C-x C-c or C-x 5 0 without killing
> the emacs daemon.
>
>
> In GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.7)
>   of 2014-03-07 on lamiak, modified by Debian
> Windowing system distributor `The X.Org Foundation', version 11.0.11501000
> System Description:    Linux Mint 17 Qiana
>
> Configured using:
>   `configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu'
>   '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
>   '--localstatedir=/var/lib' '--infodir=/usr/share/info'
>   '--mandir=/usr/share/man' '--with-pop=yes'
>   '--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp'
>   '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
>   '--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars'
>   'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
>   --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
>   'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro'
>   'CPPFLAGS=-D_FORTIFY_SOURCE=2''
>
> Important settings:
>    value of $LANG: en_IE.UTF-8
>    locale-coding-system: utf-8-unix
>    default enable-multibyte-characters: nil
>
> Major mode: Shell
>
> Minor modes in effect:
>    shell-dirtrack-mode: t
>    tooltip-mode: t
>    mouse-wheel-mode: t
>    menu-bar-mode: t
>    file-name-shadow-mode: t
>    global-font-lock-mode: t
>    font-lock-mode: t
>    blink-cursor-mode: t
>    auto-composition-mode: t
>    auto-encryption-mode: t
>    auto-compression-mode: t
>    line-number-mode: t
>    transient-mark-mode: t
>
> Recent input:
> <up> <up> <backspace> 4 C-x C-s C-x b <return> c d
> <return> t c s h <return> s s w i d l <return> c d
> , SPC ' s r c / g e n _ c u b e ' <return> C-x b <return>
> C-x b <return> g e n _ c u b e <return> M-x s h e l
> l <return> M-x r e n a m e SPC b SPC 2 <backspace>
> <return> 2 _ i d l <return> t c s h <return> s s w
> i d l <return> c d , SPC ' s r c / g e n <tab> ' <return>
> C-x b g e <tab> <return> <backspace> 8 C-x C-s C-x
> b <return> g e n _ c u b e <return> M-x s h e l l <return>
> M-x r e n a m e SPC b SPC <return> 3 _ i d l <return>
> C-x b g e n <tab> <return> <backspace> 1 2 C-x C-s
> C-x b <return> t c s h <return> s s w i d l <return>
> c d , SPC ' s r c / g e n _ c u b e ' <return> g e
> n _ c u b e <return> C-x b 0 <tab> <return> C-x C-f
> D e s k <tab> i n <tab> <return> <right> <right> <right>
> <right> <right> <right> <right> <right> <right> <right>
> <right> <right> <right> <right> <right> <right> <right>
> <right> <right> <right> C-d C-d C-d C-d C-d C-d C-d
> C-d C-d C-d <down> C-d C-d C-d C-d C-d C-d C-d C-d
> C-d C-d C-x C-s C-x k <return> M-x r e p o r t SPC
> e , a <backspace> <backspace> m a c s SPC b i g <backspace>
> <backspace> u g <return>
>
> Recent messages:
> Normalizing idlwave-system-routines in idle time...done
> Loading and normalizing library catalogs in idle time...done
> Finishing initialization in idle time...
> Scanning all buffers...
> Setting up indent for shell type sh
> setting up indent stuff
> Indentation variables are now local.
> Indentation setup for shell type sh
> Saving file /home/mel/Desktop/install.sh...
> Wrote /home/mel/Desktop/install.sh
>
> Load-path shadows:
> /usr/share/emacs/24.3/site-lisp/debian-startup hides 
> /usr/share/emacs/site-lisp/debian-startup
>
> Features:
> (shadow sort gnus-util mail-extr warnings emacsbug message format-spec
> rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
> mailabbrev gmm-utils mailheader sh-script smie executable vc-git idlwave
> imenu idlwave-help idlw-help browse-url shell pcomplete comint
> ansi-color ring color-theme cl-macs gv edmacro kmacro wid-edit cl cl-lib
> sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
> reporter easymenu jka-compr time-date tooltip ediff-hook vc-hooks
> lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
> fringe tabulated-list newcomment lisp-mode register page menu-bar
> rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
> facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
> tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
> czech european ethiopic indian cyrillic chinese case-table epa-hook
> jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
> cus-face macroexp files text-properties overlay sha1 md5 base64 format
> env code-pages mule custom widget hashtable-print-readable backquote
> make-network-process dbusbind dynamic-setting system-font-setting
> font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Message #50 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Alexis <flexibeast <at> gmail.com>
To: 17125 <at> debbugs.gnu.org
Subject: Issue still present in pretest 24.3.94.1: in daemon mode,
 closing X client frame exits entire Emacs
Date: Thu, 02 Oct 2014 12:46:34 +1000

Context: Debian Wheezy x86_64.

Daemon shutdown occurs regardless of whether one uses C-x 5 0 or C-x C-c
to close the frame.


Alexis.

Message #53 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Alexis <flexibeast <at> gmail.com>
Cc: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: Issue still present in pretest 24.3.94.1: in daemon
 mode, closing X client frame exits entire Emacs
Date: Thu, 02 Oct 2014 11:06:32 +0400

On 10/02/2014 06:46 AM, Alexis wrote:

> Daemon shutdown occurs regardless of whether one uses C-x 5 0 or C-x C-c
> to close the frame.

Usually this means that the server process is crashed.
Can you obtain the backtrace?  Recommended procedure is:

1) Compile with --with-x-toolkit=lucid --enable-checking
2) ./src/emacs -Q --daemon
3) gdb -p [pid of daemon process]
4) In gdb, install breakpoints to 'die' and 'exit', then 'c'(ontinue)
5) ./lib-src/emacsclient -nc
6) In client frame, C-x 5 0
7) See gdb output from 3).

Dmitry

Message #56 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Alexis <flexibeast <at> gmail.com>
To: 17125 <at> debbugs.gnu.org
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>
Subject: Re: bug#17125: Issue still present in pretest 24.3.94.1: in daemon
 mode, closing X client frame exits entire Emacs
Date: Thu, 02 Oct 2014 20:29:41 +1000

Dmitry Antipov writes:

> On 10/02/2014 06:46 AM, Alexis wrote:
>
>> Daemon shutdown occurs regardless of whether one uses C-x 5 0 or C-x C-c
>> to close the frame.
>
> Usually this means that the server process is crashed.
> Can you obtain the backtrace?  Recommended procedure is:
>
> 1) Compile with --with-x-toolkit=lucid --enable-checking
> 2) ./src/emacs -Q --daemon
> 3) gdb -p [pid of daemon process]
> 4) In gdb, install breakpoints to 'die' and 'exit', then 'c'(ontinue)
> 5) ./lib-src/emacsclient -nc
> 6) In client frame, C-x 5 0
> 7) See gdb output from 3).

(gdb) break die
Breakpoint 1 at 0x57ffb0: file alloc.c, line 6830.
(gdb) break exit
Breakpoint 2 at 0x7fa4fe101b60
(gdb) continue
Continuing.
[New Thread 0x7fa4f3fff700 (LWP 30109)]
[New Thread 0x7fa4f37fe700 (LWP 30110)]

Breakpoint 1, die (msg=msg <at> entry=0x664203 "VECTORP (elt)", file=file <at> entry=0x66b506 "font.c", line=line <at> entry=2602) at alloc.c:6830
6830    {
(gdb) bt
#0  die (msg=msg <at> entry=0x664203 "VECTORP (elt)", file=file <at> entry=0x66b506 "font.c", line=line <at> entry=2602) at alloc.c:6830
#1  0x00000000005b28b1 in font_clear_cache (cache=16514454, driver=driver <at> entry=0xc7ac80, f=<error reading variable: Unhandled dwarf expression opcode 0xfa>)
    at font.c:2602
#2  0x00000000005b9332 in font_finish_cache (driver=0xc7ac80, f=0x129cc28) at font.c:2566
#3  font_update_drivers (f=f <at> entry=0x129cc28, new_drivers=13144946) at font.c:3475
#4  0x0000000000427e13 in delete_frame (frame=<optimized out>, force=13144946) at frame.c:1345
#5  0x00000000005a139b in Ffuncall (nargs=nargs <at> entry=1, args=args <at> entry=0x7fff814f3e90) at eval.c:2815
#6  0x000000000059cbdc in Fcall_interactively (function=13187842, record_flag=13144946, keys=13179645) at callint.c:836
#7  0x00000000005a1387 in Ffuncall (nargs=<optimized out>, args=<optimized out>) at eval.c:2819
#8  0x00000000005df63d in exec_byte_code (bytestr=2, vector=6731014, maxdepth=2602, args_template=4100, nargs=4, args=0xfbfd80, args <at> entry=0x7fff814f4168)
    at bytecode.c:916
#9  0x00000000005a0dc0 in funcall_lambda (fun=4, nargs=nargs <at> entry=1, arg_vector=arg_vector <at> entry=0x7fff814f4168) at eval.c:2979
#10 0x00000000005a111b in Ffuncall (nargs=nargs <at> entry=2, args=args <at> entry=0x7fff814f4160) at eval.c:2873
#11 0x00000000005a15aa in call1 (fn=<optimized out>, arg1=<optimized out>) at eval.c:2611
#12 0x000000000052bbeb in command_loop_1 () at keyboard.c:1559
#13 0x000000000059f085 in internal_condition_case (bfun=bfun <at> entry=0x52b770 <command_loop_1>, handlers=<optimized out>, hfun=hfun <at> entry=0x520750 <cmd_error>)
    at eval.c:1348
#14 0x000000000051db3e in command_loop_2 (ignore=ignore <at> entry=13144946) at keyboard.c:1177
#15 0x000000000059ef8b in internal_catch (tag=13192162, func=func <at> entry=0x51db20 <command_loop_2>, arg=13144946) at eval.c:1112
#16 0x0000000000520277 in command_loop () at keyboard.c:1156
#17 recursive_edit_1 () at keyboard.c:777
#18 0x00000000005205b5 in Frecursive_edit () at keyboard.c:848
#19 0x0000000000415e05 in main (argc=3, argv=<optimized out>) at emacs.c:1646
(gdb)


Alexis.

Message #59 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Alexis <flexibeast <at> gmail.com>
Cc: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: Issue still present in pretest 24.3.94.1: in daemon
 mode, closing X client frame exits entire Emacs
Date: Thu, 02 Oct 2014 15:37:35 +0400

[Message part 1 (text/plain, inline)]

On 10/02/2014 02:29 PM, Alexis wrote:

> Breakpoint 1, die (msg=msg <at> entry=0x664203 "VECTORP (elt)", file=file <at> entry=0x66b506 "font.c", line=line <at> entry=2602) at alloc.c:6830
> 6830    {
> (gdb) bt
> #0  die (msg=msg <at> entry=0x664203 "VECTORP (elt)", file=file <at> entry=0x66b506 "font.c", line=line <at> entry=2602) at alloc.c:6830
> #1  0x00000000005b28b1 in font_clear_cache (cache=16514454, driver=driver <at> entry=0xc7ac80, f=<error reading variable: Unhandled dwarf expression opcode 0xfa>)
>      at font.c:2602
> #2  0x00000000005b9332 in font_finish_cache (driver=0xc7ac80, f=0x129cc28) at font.c:2566

This is an old issue hopefully fixed in trunk (and not in emacs-24 due to an annoying oversight).
Please try this.

Dmitry

[bug17125_fixed_4.patch (text/x-diff, attachment)]

Message #62 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Alexis <flexibeast <at> gmail.com>
To: 17125 <at> debbugs.gnu.org
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>
Subject: Re: bug#17125: Issue still present in pretest 24.3.94.1: in daemon
 mode, closing X client frame exits entire Emacs
Date: Fri, 03 Oct 2014 10:53:24 +1000

Dmitry Antipov writes:

> This is an old issue hopefully fixed in trunk (and not in emacs-24 due
> to an annoying oversight).

Ah okay, fair enough! Yes, i actually tried your patches upthread; when
the latest pretest came out, i wanted to confirm that they'd been
applied in the emacs-24 branch ....

i just built trunk as of Git commit 14bc99e6, and C-x 5 0 no longer
causes the daemon to shut down. :-)

i take it that the fix will indeed be made available in the next release
of what is to become 24.4?

Message #65 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Alexis <flexibeast <at> gmail.com>
Cc: 17125 <at> debbugs.gnu.org
Subject: Re: bug#17125: Issue still present in pretest 24.3.94.1: in daemon
 mode, closing X client frame exits entire Emacs
Date: Fri, 03 Oct 2014 07:52:44 +0400

On 10/03/2014 04:53 AM, Alexis wrote:

> i take it that the fix will indeed be made available in the next release
> of what is to become 24.4?

Now installed in emacs-24, so it should be.

Dmitry

Message #68 received at 17125 <at> debbugs.gnu.org (full text, mbox):

From: Alexis <flexibeast <at> gmail.com>
To: 17125 <at> debbugs.gnu.org
Cc: Dmitry Antipov <dmantipov <at> yandex.ru>
Subject: Re: bug#17125: Issue still present in pretest 24.3.94.1: in daemon
 mode, closing X client frame exits entire Emacs
Date: Fri, 03 Oct 2014 16:39:33 +1000

Dmitry Antipov writes:

> Now installed in emacs-24, so it should be.

i just compiled the emacs-24 branch as at Git commit 9f8e964e, using:

--with-x-toolkit=lucid

and then:

--with-x-toolkit=GTK3

In both instances, neither C-x 5 0 nor C-x C-c caused the daemon to
shut down. :-)

Thanks!


Alexis.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.