* 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[parent not found: <handler.17125.B.13959614234976.ack@debbugs.gnu.org>]
* 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).