* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.