unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs
@ 2014-03-27 22:47 Peder O. Klingenberg
       [not found] ` <handler.17125.B.13959614234976.ack@debbugs.gnu.org>
                   ` (3 more replies)
  0 siblings, 4 replies; 21+ messages in thread
From: Peder O. Klingenberg @ 2014-03-27 22:47 UTC (permalink / raw)
  To: 17125

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))





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs)
       [not found] ` <handler.17125.B.13959614234976.ack@debbugs.gnu.org>
@ 2014-04-01 11:35   ` Peder O. Klingenberg
  2014-04-01 13:47     ` Dmitry Antipov
  0 siblings, 1 reply; 21+ messages in thread
From: Peder O. Klingenberg @ 2014-04-01 11:35 UTC (permalink / raw)
  To: 17125

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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs)
  2014-04-01 11:35   ` bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs) Peder O. Klingenberg
@ 2014-04-01 13:47     ` Dmitry Antipov
  2014-04-01 14:09       ` Peder O. Klingenberg
  0 siblings, 1 reply; 21+ messages in thread
From: Dmitry Antipov @ 2014-04-01 13:47 UTC (permalink / raw)
  To: Peder O. Klingenberg; +Cc: 17125

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






^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs)
  2014-04-01 13:47     ` Dmitry Antipov
@ 2014-04-01 14:09       ` Peder O. Klingenberg
  2014-04-01 15:08         ` Dmitry Antipov
  0 siblings, 1 reply; 21+ messages in thread
From: Peder O. Klingenberg @ 2014-04-01 14:09 UTC (permalink / raw)
  To: 17125

Dmitry Antipov <dmantipov@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...





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs)
  2014-04-01 14:09       ` Peder O. Klingenberg
@ 2014-04-01 15:08         ` Dmitry Antipov
  2014-04-01 15:27           ` Andreas Schwab
  0 siblings, 1 reply; 21+ messages in thread
From: Dmitry Antipov @ 2014-04-01 15:08 UTC (permalink / raw)
  To: Peder O. Klingenberg; +Cc: 17125

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

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


[-- Attachment #2: bug17125.patch --]
[-- Type: text/x-patch, Size: 1996 bytes --]

=== modified file 'src/composite.c'
--- src/composite.c	2014-02-13 12:16:42 +0000
+++ src/composite.c	2014-04-01 14:06:38 +0000
@@ -223,7 +223,7 @@
   if (INTEGERP (components))
     key = Fmake_vector (make_number (1), components);
   else if (STRINGP (components) || CONSP (components))
-    key = Fvconcat (1, &components);
+    key = vector1 (components);
   else if (VECTORP (components))
     key = components;
   else if (NILP (components))

=== modified file 'src/font.c'
--- src/font.c	2014-03-03 19:58:20 +0000
+++ src/font.c	2014-04-01 14:32:00 +0000
@@ -2701,7 +2701,7 @@
       if (prop < FONT_SPEC_MAX)
 	val = Fcons (entity, val);
     }
-  return (Fvconcat (1, &val));
+  return vector1 (val);
 }
 
 
@@ -2756,10 +2756,7 @@
 	    Lisp_Object copy;
 
 	    val = driver_list->driver->list (f, scratch_font_spec);
-	    if (NILP (val))
-	      val = zero_vector;
-	    else
-	      val = Fvconcat (1, &val);
+	    val = NILP (val) ? zero_vector : vector1 (val);
 	    copy = copy_font_spec (scratch_font_spec);
 	    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
 	    XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache)));
@@ -2815,7 +2812,7 @@
 	    entity = driver_list->driver->match (f, work);
 	    copy = copy_font_spec (work);
 	    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
-	    XSETCDR (cache, Fcons (Fcons (copy, entity), XCDR (cache)));
+	    XSETCDR (cache, Fcons (Fcons (copy, vector1 (entity)), XCDR (cache)));
 	  }
 	if (! NILP (entity))
 	  break;

=== 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;
+}
+
 extern struct Lisp_Vector *allocate_pseudovector (int, int, enum pvec_type);
 #define ALLOCATE_PSEUDOVECTOR(typ,field,tag)				\
   ((typ*)								\


^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs)
  2014-04-01 15:08         ` Dmitry Antipov
@ 2014-04-01 15:27           ` Andreas Schwab
  2014-04-01 16:27             ` Dmitry Antipov
  0 siblings, 1 reply; 21+ messages in thread
From: Andreas Schwab @ 2014-04-01 15:27 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: Peder O. Klingenberg, 17125

Dmitry Antipov <dmantipov@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@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs)
  2014-04-01 15:27           ` Andreas Schwab
@ 2014-04-01 16:27             ` Dmitry Antipov
  2014-04-01 21:02               ` Peder O. Klingenberg
  0 siblings, 1 reply; 21+ messages in thread
From: Dmitry Antipov @ 2014-04-01 16:27 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Peder O. Klingenberg, 17125

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

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


[-- Attachment #2: bug17125_fixed.patch --]
[-- Type: text/x-patch, Size: 876 bytes --]

=== modified file 'src/font.c'
--- src/font.c	2014-03-03 19:58:20 +0000
+++ src/font.c	2014-04-01 16:23:43 +0000
@@ -2756,10 +2756,7 @@
 	    Lisp_Object copy;
 
 	    val = driver_list->driver->list (f, scratch_font_spec);
-	    if (NILP (val))
-	      val = zero_vector;
-	    else
-	      val = Fvconcat (1, &val);
+	    val = NILP (val) ? zero_vector : Fvconcat (1, &val);
 	    copy = copy_font_spec (scratch_font_spec);
 	    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
 	    XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache)));
@@ -2813,6 +2810,7 @@
 	else
 	  {
 	    entity = driver_list->driver->match (f, work);
+	    entity = NILP (entity) ? zero_vector : Fvconcat (1, &entity);
 	    copy = copy_font_spec (work);
 	    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
 	    XSETCDR (cache, Fcons (Fcons (copy, entity), XCDR (cache)));


^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs)
  2014-04-01 16:27             ` Dmitry Antipov
@ 2014-04-01 21:02               ` Peder O. Klingenberg
  2014-04-01 22:07                 ` bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs Peder O. Klingenberg
  2014-04-02  3:46                 ` bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs) Dmitry Antipov
  0 siblings, 2 replies; 21+ messages in thread
From: Peder O. Klingenberg @ 2014-04-01 21:02 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: Andreas Schwab, 17125


On 1 Apr, 2014, at 18:27, Dmitry Antipov <dmantipov@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...





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs
  2014-04-01 21:02               ` Peder O. Klingenberg
@ 2014-04-01 22:07                 ` Peder O. Klingenberg
  2014-04-02  3:46                 ` bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs) Dmitry Antipov
  1 sibling, 0 replies; 21+ messages in thread
From: Peder O. Klingenberg @ 2014-04-01 22:07 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: Andreas Schwab, 17125

On 1 Apr, 2014, at 23:02, Peder O. Klingenberg <peder@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...





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs)
  2014-04-01 21:02               ` Peder O. Klingenberg
  2014-04-01 22:07                 ` bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs Peder O. Klingenberg
@ 2014-04-02  3:46                 ` Dmitry Antipov
  2014-04-02 11:50                   ` bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs Peder O. Klingenberg
  1 sibling, 1 reply; 21+ messages in thread
From: Dmitry Antipov @ 2014-04-02  3:46 UTC (permalink / raw)
  To: Peder O. Klingenberg; +Cc: 17125

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

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



[-- Attachment #2: bug17125_fixed_2.patch --]
[-- Type: text/x-patch, Size: 1932 bytes --]

=== modified file 'src/font.c'
--- src/font.c	2014-03-03 19:58:20 +0000
+++ src/font.c	2014-04-02 03:38:22 +0000
@@ -2753,22 +2753,21 @@
 	  val = XCDR (val);
 	else
 	  {
-	    Lisp_Object copy;
-
 	    val = driver_list->driver->list (f, scratch_font_spec);
-	    if (NILP (val))
-	      val = zero_vector;
-	    else
-	      val = Fvconcat (1, &val);
-	    copy = copy_font_spec (scratch_font_spec);
-	    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
-	    XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache)));
+	    if (!NILP (val))
+	      {
+		Lisp_Object copy = copy_font_spec (scratch_font_spec);
+
+		val = Fvconcat (1, &val);
+		ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
+		XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache)));
+	      }
 	  }
-	if (ASIZE (val) > 0
+	if (VECTORP (val) && ASIZE (val) > 0
 	    && (need_filtering
 		|| ! NILP (Vface_ignored_fonts)))
 	  val = font_delete_unmatched (val, need_filtering ? spec : Qnil, size);
-	if (ASIZE (val) > 0)
+	if (VECTORP (val) && ASIZE (val) > 0)
 	  list = Fcons (val, list);
       }
 
@@ -2804,7 +2803,6 @@
 	&& (NILP (ftype) || EQ (driver_list->driver->type, ftype)))
       {
 	Lisp_Object cache = font_get_cache (f, driver_list->driver);
-	Lisp_Object copy;
 
 	ASET (work, FONT_TYPE_INDEX, driver_list->driver->type);
 	entity = assoc_no_quit (work, XCDR (cache));
@@ -2813,9 +2811,14 @@
 	else
 	  {
 	    entity = driver_list->driver->match (f, work);
-	    copy = copy_font_spec (work);
-	    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
-	    XSETCDR (cache, Fcons (Fcons (copy, entity), XCDR (cache)));
+	    if (!NILP (entity))
+	      {
+		Lisp_Object copy = copy_font_spec (work);
+		Lisp_Object match = Fvector (1, &entity);
+
+		ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
+		XSETCDR (cache, Fcons (Fcons (copy, match), XCDR (cache)));
+	      }
 	  }
 	if (! NILP (entity))
 	  break;


^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs
  2014-04-02  3:46                 ` bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs) Dmitry Antipov
@ 2014-04-02 11:50                   ` Peder O. Klingenberg
  2014-04-02 12:24                     ` Dmitry Antipov
  0 siblings, 1 reply; 21+ messages in thread
From: Peder O. Klingenberg @ 2014-04-02 11:50 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17125

Dmitry Antipov <dmantipov@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...





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs
  2014-04-02 11:50                   ` bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs Peder O. Klingenberg
@ 2014-04-02 12:24                     ` Dmitry Antipov
  2014-04-02 13:01                       ` Peder O. Klingenberg
  0 siblings, 1 reply; 21+ messages in thread
From: Dmitry Antipov @ 2014-04-02 12:24 UTC (permalink / raw)
  To: Peder O. Klingenberg; +Cc: 17125

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

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


[-- Attachment #2: bug17125_fixed_3.patch --]
[-- Type: text/x-patch, Size: 1453 bytes --]

=== modified file 'src/font.c'
--- src/font.c	2014-03-03 19:58:20 +0000
+++ src/font.c	2014-04-02 12:12:21 +0000
@@ -2753,14 +2753,10 @@
 	  val = XCDR (val);
 	else
 	  {
-	    Lisp_Object copy;
+	    Lisp_Object copy = copy_font_spec (scratch_font_spec);
 
 	    val = driver_list->driver->list (f, scratch_font_spec);
-	    if (NILP (val))
-	      val = zero_vector;
-	    else
-	      val = Fvconcat (1, &val);
-	    copy = copy_font_spec (scratch_font_spec);
+	    val = NILP (val) ? zero_vector : Fvconcat (1, &val);
 	    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
 	    XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache)));
 	  }
@@ -2804,7 +2800,6 @@
 	&& (NILP (ftype) || EQ (driver_list->driver->type, ftype)))
       {
 	Lisp_Object cache = font_get_cache (f, driver_list->driver);
-	Lisp_Object copy;
 
 	ASET (work, FONT_TYPE_INDEX, driver_list->driver->type);
 	entity = assoc_no_quit (work, XCDR (cache));
@@ -2812,10 +2807,12 @@
 	  entity = XCDR (entity);
 	else
 	  {
+	    Lisp_Object match, copy = copy_font_spec (work);
+
 	    entity = driver_list->driver->match (f, work);
-	    copy = copy_font_spec (work);
+	    match = NILP (entity) ? zero_vector : Fvector (1, &match);
 	    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
-	    XSETCDR (cache, Fcons (Fcons (copy, entity), XCDR (cache)));
+	    XSETCDR (cache, Fcons (Fcons (copy, match), XCDR (cache)));
 	  }
 	if (! NILP (entity))
 	  break;


^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs
  2014-04-02 12:24                     ` Dmitry Antipov
@ 2014-04-02 13:01                       ` Peder O. Klingenberg
  0 siblings, 0 replies; 21+ messages in thread
From: Peder O. Klingenberg @ 2014-04-02 13:01 UTC (permalink / raw)
  To: Dmitry Antipov; +Cc: 17125

Dmitry Antipov <dmantipov@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...





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs
  2014-03-27 22:47 bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs Peder O. Klingenberg
       [not found] ` <handler.17125.B.13959614234976.ack@debbugs.gnu.org>
@ 2014-07-11  9:01 ` Alexis
  2014-10-02  2:46 ` bug#17125: Issue still present in pretest 24.3.94.1: in daemon mode, closing X client frame exits entire Emacs Alexis
  2014-10-03  6:39 ` Alexis
  3 siblings, 0 replies; 21+ messages in thread
From: Alexis @ 2014-07-11  9:01 UTC (permalink / raw)
  To: 17125


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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Issue still present in pretest 24.3.94.1: in daemon mode, closing X client frame exits entire Emacs
  2014-03-27 22:47 bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs Peder O. Klingenberg
       [not found] ` <handler.17125.B.13959614234976.ack@debbugs.gnu.org>
  2014-07-11  9:01 ` Alexis
@ 2014-10-02  2:46 ` Alexis
  2014-10-02  7:06   ` Dmitry Antipov
  2014-10-03  6:39 ` Alexis
  3 siblings, 1 reply; 21+ messages in thread
From: Alexis @ 2014-10-02  2:46 UTC (permalink / raw)
  To: 17125


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.







^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Issue still present in pretest 24.3.94.1: in daemon mode, closing X client frame exits entire Emacs
  2014-10-02  2:46 ` bug#17125: Issue still present in pretest 24.3.94.1: in daemon mode, closing X client frame exits entire Emacs Alexis
@ 2014-10-02  7:06   ` Dmitry Antipov
  2014-10-02 10:29     ` Alexis
  0 siblings, 1 reply; 21+ messages in thread
From: Dmitry Antipov @ 2014-10-02  7:06 UTC (permalink / raw)
  To: Alexis; +Cc: 17125

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






^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Issue still present in pretest 24.3.94.1: in daemon mode, closing X client frame exits entire Emacs
  2014-10-02  7:06   ` Dmitry Antipov
@ 2014-10-02 10:29     ` Alexis
  2014-10-02 11:37       ` Dmitry Antipov
  0 siblings, 1 reply; 21+ messages in thread
From: Alexis @ 2014-10-02 10:29 UTC (permalink / raw)
  To: 17125; +Cc: Dmitry Antipov


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@entry=0x664203 "VECTORP (elt)", file=file@entry=0x66b506 "font.c", line=line@entry=2602) at alloc.c:6830
6830    {
(gdb) bt
#0  die (msg=msg@entry=0x664203 "VECTORP (elt)", file=file@entry=0x66b506 "font.c", line=line@entry=2602) at alloc.c:6830
#1  0x00000000005b28b1 in font_clear_cache (cache=16514454, driver=driver@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@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@entry=1, args=args@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@entry=0x7fff814f4168)
    at bytecode.c:916
#9  0x00000000005a0dc0 in funcall_lambda (fun=4, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x7fff814f4168) at eval.c:2979
#10 0x00000000005a111b in Ffuncall (nargs=nargs@entry=2, args=args@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@entry=0x52b770 <command_loop_1>, handlers=<optimized out>, hfun=hfun@entry=0x520750 <cmd_error>)
    at eval.c:1348
#14 0x000000000051db3e in command_loop_2 (ignore=ignore@entry=13144946) at keyboard.c:1177
#15 0x000000000059ef8b in internal_catch (tag=13192162, func=func@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.





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Issue still present in pretest 24.3.94.1: in daemon mode, closing X client frame exits entire Emacs
  2014-10-02 10:29     ` Alexis
@ 2014-10-02 11:37       ` Dmitry Antipov
  2014-10-03  0:53         ` Alexis
  0 siblings, 1 reply; 21+ messages in thread
From: Dmitry Antipov @ 2014-10-02 11:37 UTC (permalink / raw)
  To: Alexis; +Cc: 17125

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

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

> Breakpoint 1, die (msg=msg@entry=0x664203 "VECTORP (elt)", file=file@entry=0x66b506 "font.c", line=line@entry=2602) at alloc.c:6830
> 6830    {
> (gdb) bt
> #0  die (msg=msg@entry=0x664203 "VECTORP (elt)", file=file@entry=0x66b506 "font.c", line=line@entry=2602) at alloc.c:6830
> #1  0x00000000005b28b1 in font_clear_cache (cache=16514454, driver=driver@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


[-- Attachment #2: bug17125_fixed_4.patch --]
[-- Type: text/x-diff, Size: 1999 bytes --]

=== modified file 'src/font.c'
--- src/font.c	2014-09-16 04:07:51 +0000
+++ src/font.c	2014-10-02 11:09:25 +0000
@@ -2756,22 +2756,21 @@
 	  val = XCDR (val);
 	else
 	  {
-	    Lisp_Object copy;
-
 	    val = driver_list->driver->list (f, scratch_font_spec);
-	    if (NILP (val))
-	      val = zero_vector;
-	    else
-	      val = Fvconcat (1, &val);
-	    copy = copy_font_spec (scratch_font_spec);
-	    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
-	    XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache)));
+	    if (!NILP (val))
+	      {
+		Lisp_Object copy = copy_font_spec (scratch_font_spec);
+
+		val = Fvconcat (1, &val);
+		ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
+		XSETCDR (cache, Fcons (Fcons (copy, val), XCDR (cache)));
+	      }
 	  }
-	if (ASIZE (val) > 0
+	if (VECTORP (val) && ASIZE (val) > 0
 	    && (need_filtering
 		|| ! NILP (Vface_ignored_fonts)))
 	  val = font_delete_unmatched (val, need_filtering ? spec : Qnil, size);
-	if (ASIZE (val) > 0)
+	if (VECTORP (val) && ASIZE (val) > 0)
 	  list = Fcons (val, list);
       }
 
@@ -2807,18 +2806,22 @@
 	&& (NILP (ftype) || EQ (driver_list->driver->type, ftype)))
       {
 	Lisp_Object cache = font_get_cache (f, driver_list->driver);
-	Lisp_Object copy;
 
 	ASET (work, FONT_TYPE_INDEX, driver_list->driver->type);
 	entity = assoc_no_quit (work, XCDR (cache));
 	if (CONSP (entity))
-	  entity = XCDR (entity);
+	  entity = AREF (XCDR (entity), 0);
 	else
 	  {
 	    entity = driver_list->driver->match (f, work);
-	    copy = copy_font_spec (work);
-	    ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
-	    XSETCDR (cache, Fcons (Fcons (copy, entity), XCDR (cache)));
+	    if (!NILP (entity))
+	      {
+		Lisp_Object copy = copy_font_spec (work);
+		Lisp_Object match = Fvector (1, &entity);
+
+		ASET (copy, FONT_TYPE_INDEX, driver_list->driver->type);
+		XSETCDR (cache, Fcons (Fcons (copy, match), XCDR (cache)));
+	      }
 	  }
 	if (! NILP (entity))
 	  break;


^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Issue still present in pretest 24.3.94.1: in daemon mode, closing X client frame exits entire Emacs
  2014-10-02 11:37       ` Dmitry Antipov
@ 2014-10-03  0:53         ` Alexis
  2014-10-03  3:52           ` Dmitry Antipov
  0 siblings, 1 reply; 21+ messages in thread
From: Alexis @ 2014-10-03  0:53 UTC (permalink / raw)
  To: 17125; +Cc: Dmitry Antipov


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?





^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Issue still present in pretest 24.3.94.1: in daemon mode, closing X client frame exits entire Emacs
  2014-10-03  0:53         ` Alexis
@ 2014-10-03  3:52           ` Dmitry Antipov
  0 siblings, 0 replies; 21+ messages in thread
From: Dmitry Antipov @ 2014-10-03  3:52 UTC (permalink / raw)
  To: Alexis; +Cc: 17125

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







^ permalink raw reply	[flat|nested] 21+ messages in thread

* bug#17125: Issue still present in pretest 24.3.94.1: in daemon mode, closing X client frame exits entire Emacs
  2014-03-27 22:47 bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs Peder O. Klingenberg
                   ` (2 preceding siblings ...)
  2014-10-02  2:46 ` bug#17125: Issue still present in pretest 24.3.94.1: in daemon mode, closing X client frame exits entire Emacs Alexis
@ 2014-10-03  6:39 ` Alexis
  3 siblings, 0 replies; 21+ messages in thread
From: Alexis @ 2014-10-03  6:39 UTC (permalink / raw)
  To: 17125; +Cc: Dmitry Antipov


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.






^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2014-10-03  6:39 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-03-27 22:47 bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs Peder O. Klingenberg
     [not found] ` <handler.17125.B.13959614234976.ack@debbugs.gnu.org>
2014-04-01 11:35   ` bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs) Peder O. Klingenberg
2014-04-01 13:47     ` Dmitry Antipov
2014-04-01 14:09       ` Peder O. Klingenberg
2014-04-01 15:08         ` Dmitry Antipov
2014-04-01 15:27           ` Andreas Schwab
2014-04-01 16:27             ` Dmitry Antipov
2014-04-01 21:02               ` Peder O. Klingenberg
2014-04-01 22:07                 ` bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs Peder O. Klingenberg
2014-04-02  3:46                 ` bug#17125: Acknowledgement (24.4.50; daemon mode: closing X client frame exits entire emacs) Dmitry Antipov
2014-04-02 11:50                   ` bug#17125: 24.4.50; daemon mode: closing X client frame exits entire emacs Peder O. Klingenberg
2014-04-02 12:24                     ` Dmitry Antipov
2014-04-02 13:01                       ` Peder O. Klingenberg
2014-07-11  9:01 ` Alexis
2014-10-02  2:46 ` bug#17125: Issue still present in pretest 24.3.94.1: in daemon mode, closing X client frame exits entire Emacs Alexis
2014-10-02  7:06   ` Dmitry Antipov
2014-10-02 10:29     ` Alexis
2014-10-02 11:37       ` Dmitry Antipov
2014-10-03  0:53         ` Alexis
2014-10-03  3:52           ` Dmitry Antipov
2014-10-03  6:39 ` Alexis

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).