* bug#9943: 24.0.91; Abort in check_glyph_memory
@ 2011-11-03 9:17 martin rudalics
2011-11-03 19:08 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: martin rudalics @ 2011-11-03 9:17 UTC (permalink / raw)
To: 9943
With emacs -Q evaluating
(setq default-frame-alist (cons '(height . 0.2) default-frame-alist))
and subsequently doing
C-x 5 2
C-x C-c
gets me
Breakpoint 1, w32_abort () at w32fns.c:7187
7187 button = MessageBox (NULL,
(gdb) bt
#0 w32_abort () at w32fns.c:7187
#1 0x010628ad in check_glyph_memory () at dispnew.c:2370
#2 0x01002eaa in shut_down_emacs (sig=0, no_x=0, stuff=50190362)
at emacs.c:2102
#3 0x01002da6 in Fkill_emacs (arg=50190362) at emacs.c:2014
#4 0x01022963 in Ffuncall (nargs=1, args=0x82f420) at eval.c:2974
#5 0x010c99cb in exec_byte_code (bytestr=19232745, vector=19232765,
maxdepth=20, args_template=50190362, nargs=0, args=0x0) at bytecode.c:785
#6 0x01023282 in funcall_lambda (fun=19232717, nargs=1, arg_vector=0x82f674)
at eval.c:3205
#7 0x01022b80 in Ffuncall (nargs=2, args=0x82f670) at eval.c:3023
#8 0x010c99cb in exec_byte_code (bytestr=19232977, vector=19232997,
maxdepth=12, args_template=50190362, nargs=0, args=0x0) at bytecode.c:785
#9 0x01023282 in funcall_lambda (fun=19232949, nargs=1, arg_vector=0x82f904)
at eval.c:3205
#10 0x01022b80 in Ffuncall (nargs=2, args=0x82f900) at eval.c:3023
#11 0x010c8d97 in Fcall_interactively (function=51032882,
record_flag=50190362, keys=50211589) at callint.c:859
#12 0x010229b7 in Ffuncall (nargs=4, args=0x82fb90) at eval.c:2981
#13 0x01022372 in call3 (fn=50310506, arg1=51032882, arg2=50190362,
arg3=50190362) at eval.c:2774
#14 0x010132fa in Fcommand_execute (cmd=51032882, record_flag=50190362,
keys=50190362, special=50190362) at keyboard.c:10292
#15 0x01005069 in command_loop_1 () at keyboard.c:1570
#16 0x0101ffc1 in internal_condition_case (bfun=0x1004950 <command_loop_1>,
handlers=50248090, hfun=0x100433c <cmd_error>) at eval.c:1499
#17 0x010046ac in command_loop_2 (ignore=50190362) at keyboard.c:1158
#18 0x0101fa97 in internal_catch (tag=50246114,
func=0x1004689 <command_loop_2>, arg=50190362) at eval.c:1256
#19 0x01004664 in command_loop () at keyboard.c:1137
#20 0x01003f72 in recursive_edit_1 () at keyboard.c:757
#21 0x010040bc in Frecursive_edit () at keyboard.c:821
#22 0x01002763 in main (argc=2, argv=0xa327e0) at emacs.c:1707
Lisp Backtrace:
"kill-emacs" (0x82f424)
"save-buffers-kill-emacs" (0x82f674)
"save-buffers-kill-terminal" (0x82f904)
"call-interactively" (0x82fb94)
(gdb)
In GNU Emacs 24.0.91.1 (i386-mingw-nt5.1.2600)
of 2011-11-02 on NESTOR
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --no-opt'
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-03 9:17 bug#9943: 24.0.91; Abort in check_glyph_memory martin rudalics
@ 2011-11-03 19:08 ` Eli Zaretskii
2011-11-03 19:58 ` Glenn Morris
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-11-03 19:08 UTC (permalink / raw)
To: martin rudalics; +Cc: 9943
> Date: Thu, 03 Nov 2011 10:17:00 +0100
> From: martin rudalics <rudalics@gmx.at>
>
> With emacs -Q evaluating
>
> (setq default-frame-alist (cons '(height . 0.2) default-frame-alist))
>
> and subsequently doing
>
> C-x 5 2
> C-x C-c
>
> gets me
>
> Breakpoint 1, w32_abort () at w32fns.c:7187
> 7187 button = MessageBox (NULL,
> (gdb) bt
> #0 w32_abort () at w32fns.c:7187
> #1 0x010628ad in check_glyph_memory () at dispnew.c:2370
I fixed this for w32 (revision 106273 on the trunk). I think the same
problem can happen on X, but I cannot run Emacs on X where I'm typing
this. Could someone please try the recipe on X and see if the same
problem happens there? It could matter which toolkit was used to
build Emacs, so please tell which toolkit you are using. TIA.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-03 19:08 ` Eli Zaretskii
@ 2011-11-03 19:58 ` Glenn Morris
2011-11-03 21:05 ` Ken Brown
2011-11-03 21:57 ` Eli Zaretskii
0 siblings, 2 replies; 14+ messages in thread
From: Glenn Morris @ 2011-11-03 19:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9943
Eli Zaretskii wrote:
> I fixed this for w32 (revision 106273 on the trunk). I think the same
> problem can happen on X, but I cannot run Emacs on X where I'm typing
> this. Could someone please try the recipe on X and see if the same
> problem happens there? It could matter which toolkit was used to
> build Emacs, so please tell which toolkit you are using. TIA.
Lucid toolkit:
Breakpoint 1, abort () at emacs.c:386
386 kill (getpid (), SIGABRT);
(gdb) bt full
#0 abort () at emacs.c:386
No locals.
#1 0x0000000000414ac5 in check_glyph_memory () at dispnew.c:2370
tail = 12777890
frame = 17795205
#2 0x0000000000557bed in shut_down_emacs (sig=0, no_x=0, stuff=12777890)
at emacs.c:2102
No locals.
#3 0x0000000000557a81 in Fkill_emacs (arg=12777890) at emacs.c:2014
gcpro1 = {
next = 0xccaa32,
var = 0xc2f9a2,
nvars = 12777890
}
hook = 12942546
exit_code = 0
#4 0x00000000005fb2f8 in Ffuncall (nargs=1, args=0x7fffffff4550)
at eval.c:2974
fun = 9416221
original_fun = 12942018
funcar = 12777890
numargs = 0
lisp_numargs = 13905136
val = 12777938
backtrace = {
next = 0x7fffffff49a0,
function = 0x7fffffff4550,
args = 0x7fffffff4558,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x7fffffff4490
i = 1
#5 0x0000000000648108 in exec_byte_code (bytestr=9893129, vector=9893165,
maxdepth=20, args_template=12777890, nargs=0, args=0x0) at bytecode.c:785
count = 7
op = 0
vectorp = 0x96f538
stack = {
pc = 0xb6f949 "\207",
byte_string = 9893129,
byte_string_start = 0xb6f8ea "Ä\bÅ\"\210ÅÆÇÈ \">\203\025",
constants = 9893165,
next = 0x7fffffff4a90
}
top = 0x7fffffff4550
result = 17872832
#6 0x00000000005fbd66 in funcall_lambda (fun=9893069, nargs=1, arg_vector=
0x96f52d) at eval.c:3205
val = 13444946
syms_left = 12777890
next = 13186722
lexenv = 12777890
count = 6
i = 1
optional = 1
rest = 0
#7 0x00000000005fb50a in Ffuncall (nargs=2, args=0x7fffffff4a30)
at eval.c:3023
fun = 9893069
original_fun = 13413058
funcar = 1320350112
numargs = 1
lisp_numargs = -1
val = 12777890
backtrace = {
next = 0x7fffffff4e70,
function = 0x7fffffff4a30,
args = 0x7fffffff4a38,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x96f6f5
i = 4294967296
#8 0x0000000000648108 in exec_byte_code (bytestr=9893585, vector=9893621,
maxdepth=12, args_template=12777890, nargs=0, args=0x0) at bytecode.c:785
count = 6
op = 1
vectorp = 0x96f700
stack = {
pc = 0xb6f83d "\207",
byte_string = 9893585,
byte_string_start = 0xb6f82e "ÁÂ Ã\"\203\f",
constants = 9893621,
next = 0x0
}
top = 0x7fffffff4a30
result = 10787133
#9 0x00000000005fbd66 in funcall_lambda (fun=9893525, nargs=1, arg_vector=
0x96f6f5) at eval.c:3205
val = 20008694
syms_left = 12777890
next = 13186722
lexenv = 12777890
count = 5
i = 1
optional = 1
rest = 0
#10 0x00000000005fb50a in Ffuncall (nargs=2, args=0x7fffffff4f50)
at eval.c:3023
fun = 9893525
original_fun = 13905234
funcar = 12777890
numargs = 1
lisp_numargs = 140737488310000
val = 5608658
backtrace = {
next = 0x7fffffff5240,
function = 0x7fffffff4f50,
args = 0x7fffffff4f58,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0xb8094b
i = 140737488310000
#11 0x00000000005f5405 in Fcall_interactively (function=13905234, record_flag=
12777890, keys=12824213) at callint.c:859
val = 0
args = 0x7fffffff4f50
visargs = 0x7fffffff4f30
specs = 9720953
filter_specs = 9720953
teml = 0
up_event = 12777890
enable = 12777890
speccount = 3
next_event = 2
prefix_arg = 12777890
string = 0x7fffffff4f70 "P"
tem = 0x6beaec ""
varies = 0x7fffffff4f10 ""
i = 2
nargs = 2
foo = 0
prompt1 = '\000' <repeats 99 times>
tem1 = 0x0
arg_from_tty = 0
gcpro1 = {
next = 0x7fffffff50a0,
var = 0x3b4389aaaa,
nvars = 0
}
gcpro2 = {
next = 0x7fffffff5030,
var = 0x7ffff7ffe8bc,
nvars = 1
}
gcpro3 = {
next = 0x7fffffff5010,
var = 0x7ffff7ffe814,
nvars = 2
}
gcpro4 = {
next = 0x0,
var = 0xc2f9a2,
nvars = 2
}
gcpro5 = {
next = 0x7fffffff5030,
var = 0x5fbd7b,
nvars = 0
}
key_count = 2
record_then_fail = 0
save_this_command = 13905234
save_last_command = 15856130
save_this_original_command = 13905234
save_real_this_command = 13905234
#12 0x00000000005fb34e in Ffuncall (nargs=4, args=0x7fffffff52f0)
at eval.c:2981
fun = 12150765
original_fun = 12920322
funcar = 0
numargs = 3
lisp_numargs = 0
val = 0
backtrace = {
next = 0x0,
function = 0x7fffffff52f0,
args = 0x7fffffff52f8,
nargs = 3,
debug_on_exit = 0
}
internal_args = 0x7fffffff52f8
i = 0
#13 0x00000000005fab01 in call3 (fn=12920322, arg1=13905234, arg2=12777890,
arg3=12777890) at eval.c:2774
ret_ungc_val = 12777890
gcpro1 = {
next = 0x7fffffff5330,
var = 0x96f695,
nvars = 4
}
args = {12920322,
13905234,
12777890,
12777890}
#14 0x000000000056c86e in Fcommand_execute (cmd=13905234, record_flag=
12777890, keys=12777890, special=12777890) at keyboard.c:10292
final = 13905234
tem = 12777890
prefixarg = 12777890
#15 0x000000000055a4cf in command_loop_1 () at keyboard.c:1570
scount = 2
cmd = 13905234
keybuf = {96,
12,
140737488311424,
6417217,
14509458,
140737488311520,
12777938,
15585494,
0,
2,
140737488311360,
12830178,
9442785,
12777890,
12777890,
4300115827,
9949569,
140737488311232,
9442774,
19580943,
140737488311424,
12777938,
140737488311488,
5609546,
140737488311520,
15585494,
4262240,
17795200,
2,
4262240}
i = 2
prev_modiff = 22
prev_buffer = 0xc36730
already_adjusted = 0
#16 0x00000000005f7f4e in internal_condition_case (bfun=
0x559c49 <command_loop_1>, handlers=12830082, hfun=0x559538 <cmd_error>)
at eval.c:1499
val = 0
c = {
tag = 12777890,
val = 12777890,
next = 0x7fffffff5710,
gcpro = 0x0,
jmp = {{
__jmpbuf = {0,
2020822257688043310,
4262240,
140737488313584,
0,
0,
2020822257564311342,
-2020822783300411602},
__mask_was_saved = 0,
__saved_mask = {
__val = {16425921290409140014,
0,
4294967295,
13255638,
1,
9389848,
0,
0,
0,
0,
254531395296,
1,
0,
16122016,
254535570944,
16122016}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 12830082,
var = 12777890,
chosen_clause = 12777938,
tag = 0x7fffffff5590,
next = 0x0
}
#17 0x0000000000559938 in command_loop_2 (ignore=12777890) at keyboard.c:1158
val = 0
#18 0x00000000005f78d8 in internal_catch (tag=12825874, func=
0x559912 <command_loop_2>, arg=12777890) at eval.c:1256
c = {
tag = 12825874,
val = 12777890,
next = 0x0,
gcpro = 0x0,
jmp = {{
__jmpbuf = {2,
2020822257467842350,
4262240,
140737488313584,
0,
0,
2020822257679654702,
-2020822783234089170},
__mask_was_saved = 0,
__saved_mask = {
__val = {6154998,
0,
4301646765,
0,
12777890,
13022400,
140737488312408,
14,
12805936,
12183744,
6153577,
140737488312368,
12777890,
4262240,
140737488313584,
140737488312384}
}
}},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 1,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#19 0x00000000005598eb in command_loop () at keyboard.c:1137
No locals.
#20 0x000000000055907c in recursive_edit_1 () at keyboard.c:757
count = 1
val = 5607989
#21 0x000000000055921f in Frecursive_edit () at keyboard.c:821
count = 0
buffer = 12777890
#22 0x0000000000557397 in main (argc=2, argv=0x7fffffff5cf8) at emacs.c:1707
dummy = 254535599936
stack_bottom_variable = 0 '\000'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 33554432,
rlim_max = 18446744073709551615
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x7ffff7652358 "@\024bC;"
Lisp Backtrace:
"kill-emacs" (0xffff4558)
"save-buffers-kill-emacs" (0xffff4a38)
"save-buffers-kill-terminal" (0xffff4f58)
"call-interactively" (0xffff52f8)
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-03 19:58 ` Glenn Morris
@ 2011-11-03 21:05 ` Ken Brown
2011-11-03 21:59 ` Eli Zaretskii
2011-11-03 21:57 ` Eli Zaretskii
1 sibling, 1 reply; 14+ messages in thread
From: Ken Brown @ 2011-11-03 21:05 UTC (permalink / raw)
To: Glenn Morris; +Cc: 9943
On 11/3/2011 3:58 PM, Glenn Morris wrote:
> Eli Zaretskii wrote:
>
>> I fixed this for w32 (revision 106273 on the trunk). I think the same
>> problem can happen on X, but I cannot run Emacs on X where I'm typing
>> this. Could someone please try the recipe on X and see if the same
>> problem happens there? It could matter which toolkit was used to
>> build Emacs, so please tell which toolkit you are using. TIA.
>
> Lucid toolkit:
[...]
Eli,
I don't know if you need results from a second toolkit, but here's what
I get with gtk:
(gdb) bt full
#0 abort () at emacs.c:386
No locals.
#1 0x00404781 in check_glyph_memory () at dispnew.c:2370
tail = 8775706
frame = -2147299323
#2 0x005149e8 in shut_down_emacs (sig=0, no_x=0, stuff=8775706)
at emacs.c:2102
No locals.
#3 0x005148ae in Fkill_emacs (arg=8775706) at emacs.c:2014
gcpro1 = {
next = 0x96053a,
var = 0x85e81a,
nvars = 8775706
}
hook = 8960458
exit_code = 2670032
#4 0x00596763 in Ffuncall (nargs=1, args=0x28be90) at eval.c:2974
fun = 6464037
original_fun = 8960194
funcar = 8775682
numargs = 0
lisp_numargs = 0
val = 8775730
backtrace = {
next = 0x28c13c,
function = 0x28be90,
args = 0x28be94,
nargs = 0,
debug_on_exit = 0
}
internal_args = 0x28bdd0
i = 1
#5 0x005d4a01 in exec_byte_code (bytestr=6706281, vector=6706301,
maxdepth=20, args_template=8775706, nargs=0, args=0x0) at
bytecode.c:785
count = 7
op = 0
vectorp = 0x665480
stack = {
pc = 0x7959b4 "\207",
byte_string = 6706281,
byte_string_start = 0x795955
"\304\b\305\"\210\305\306\307\310 \">\203\025",
constants = 6706301,
next = 0x28c1d4
}
top = 0x28be90
result = 5734137
#6 0x005970a0 in funcall_lambda (fun=6706253, nargs=1, arg_vector=0x85e81a)
at eval.c:3205
val = 8775706
syms_left = 8775706
next = 9156754
lexenv = 8775706
count = 6
i = 1
optional = 1
rest = 0
#7 0x00596982 in Ffuncall (nargs=2, args=0x28c1a0) at eval.c:3023
fun = 6706253
original_fun = 9831810
funcar = 2671128
numargs = 1
lisp_numargs = 8825122
val = 8775706
backtrace = {
next = 0x28c43c,
function = 0x28c1a0,
args = 0x28c1a4,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x85e81a
i = 11974706
#8 0x005d4a01 in exec_byte_code (bytestr=6706513, vector=6706533,
maxdepth=12, args_template=8775706, nargs=0, args=0x0) at
bytecode.c:785
count = 6
op = 1
vectorp = 0x665568
stack = {
pc = 0x7958a8 "\207",
byte_string = 6706513,
byte_string_start = 0x795899 "\301\302 \303\"\203\f",
constants = 6706533,
next = 0x0
}
top = 0x28c1a0
result = 6113793
#9 0x005970a0 in funcall_lambda (fun=6706485, nargs=1, arg_vector=0x85e81a)
at eval.c:3205
val = 8775706
syms_left = 8775706
next = 9156754
lexenv = 8775706
count = 5
i = 1
optional = 1
rest = 0
#10 0x00596982 in Ffuncall (nargs=2, args=0x28c4f0) at eval.c:3023
fun = 6706485
original_fun = 9831906
funcar = 5832270
numargs = 1
lisp_numargs = 5320791
val = 8775706
backtrace = {
next = 0x28c73c,
function = 0x28c4f0,
args = 0x28c4f4,
nargs = 1,
debug_on_exit = 0
}
internal_args = 0x28c7a4
i = 8775706
#11 0x00591a56 in Fcall_interactively (function=9831906,
record_flag=8775706,
keys=8554501) at callint.c:859
val = 2818091
args = 0x28c4f0
visargs = 0x28c4d0
specs = 6618545
filter_specs = 6618545
teml = 1628407553
up_event = 8775706
enable = 8775706
speccount = 3
next_event = 2
prefix_arg = 8775706
string = 0x28c510 "P"
tem = 0x7d29ec ""
varies = 0x28c4b0 ""
i = 2
nargs = 2
foo = 0
prompt1 = '\000' <repeats 99 times>
tem1 = 0x0
arg_from_tty = 0
gcpro1 = {
next = 0x2,
var = 0x85e81a,
nvars = 7329013
}
gcpro2 = {
next = 0xb6b25a,
var = 0x85e81a,
nvars = 0
}
gcpro3 = {
next = 0x52b07c,
var = 0x868005,
nvars = 2
}
gcpro4 = {
next = 0x28c600,
var = 0x28c604,
nvars = 2
}
gcpro5 = {
next = 0x85e81a,
var = 0x9605e2,
nvars = 0
}
key_count = 2
record_then_fail = 0
save_this_command = 9831906
save_last_command = 13030146
save_this_original_command = 9831906
save_real_this_command = 9831906
#12 0x005967ae in Ffuncall (nargs=4, args=0x28c7a0) at eval.c:2981
fun = 8101333
original_fun = 8945050
funcar = 0
numargs = 3
lisp_numargs = 0
val = 1320352601
backtrace = {
next = 0x0,
function = 0x28c7a0,
args = 0x28c7a4,
nargs = 3,
debug_on_exit = 0
}
internal_args = 0x28c7a4
i = 0
#13 0x00596179 in call3 (fn=8945050, arg1=9831906, arg2=8775706,
arg3=8775706)
at eval.c:2774
ret_ungc_val = 6706485
gcpro1 = {
next = 0x85e81a,
var = 0x86796a,
nvars = 4
}
args = {8945050, 9831906, 8775706, 8775706}
#14 0x00524b8b in Fcommand_execute (cmd=9831906, record_flag=8775706,
keys=8775706, special=8775706) at keyboard.c:10292
final = 6706485
tem = 8775706
prefixarg = 8775706
#15 0x00516c59 in command_loop_1 () at keyboard.c:1570
scount = 2
cmd = 9831906
keybuf = {96, 12, 2672640, 6734985, 1, 8775706, 8775706, 6477329,
2672736, 8110664, 2672792, 5333428, 13560702, 8775730, 2672831,
9216194, 8930098, 8775706, 8758782, -2147299328, 0, -2147365760,
2672888, 5333002, 13560702, 2672831, 2672856, 5853201, 2,
8758782}
i = 2
prev_modiff = 24
prev_buffer = 0x863c00
already_adjusted = 0
#16 0x00593f0e in internal_condition_case (bfun=0x51653f <command_loop_1>,
handlers=8825218, hfun=0x515f1f <cmd_error>) at eval.c:1499
val = 8758782
c = {
tag = 8775706,
val = 8775706,
next = 0x28ca74,
gcpro = 0x0,
jmp = {2672960, 0, 32, -2147188704, 2, 5320791, 2673208,
2672896,
5848745, 5439531, 2818091, 2686784, 2677296, 8110660,
-2147366528,
2674276, 0, -552734650, 2673240, 2672992, 1628354534, 5439531,
2818091, 2686784, 0, 0, 0, 8110660, 2, 5320791, 2673336,
1628384438, -2147366528, 0, 2673096, 8110660, 0, 3, 2673112,
8110660, 0, 2674276, 2, 5320791, 2673336, 2673088, 1628384355,
5439531, 2818091, 2686784, 2673224, 1628363639},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 0,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
h = {
handler = 8825218,
var = 8775706,
chosen_clause = 8775730,
tag = 0x28c930,
next = 0x0
}
#17 0x00516290 in command_loop_2 (ignore=8775706) at keyboard.c:1158
val = 0
#18 0x005939e0 in internal_catch (tag=8823242, func=0x51626c
<command_loop_2>,
arg=8775706) at eval.c:1256
c = {
tag = 8823242,
val = 8775706,
next = 0x0,
gcpro = 0x0,
jmp = {2673284, -2147365760, 32, -2147188704, 2, 5320791,
2673528,
2673248, 5847505, 5439531, 2818091, 2686784, 2677296,
-2147365760,
6314967, 8110660, 41, 0, -2147367168, 3, 10, 2673416,
-2147366656,
8559424, 41, 2673432, 6315042, 8559360, 41, 100, 0, 0,
-2147365760, 2673448, 0, 8559424, 41, 2673464, 2, 5320791,
8775706, 2673528, 5761671, 8246376, 8775706, 8797184, 6186777,
10422672, -2147365760, 8246376, 8797184, 8246376},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0,
pdlcount = 2,
poll_suppress_count = 0,
interrupt_input_blocked = 0,
byte_stack = 0x0
}
#19 0x0051624c in command_loop () at keyboard.c:1137
No locals.
#20 0x00515b58 in recursive_edit_1 () at keyboard.c:757
count = 1
val = 2673640
#21 0x00515ca9 in Frecursive_edit () at keyboard.c:821
count = 0
buffer = 8775706
#22 0x0051431a in main (argc=2, argv=0x28ccf0) at emacs.c:1707
dummy = 1629631048
stack_bottom_variable = 97 'a'
do_initial_setlocale = 1
skip_args = 0
rlim = {
rlim_cur = 2097082,
rlim_max = 2097152
}
no_loadup = 0
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x1 <Address 0x1 out of bounds>
Lisp Backtrace:
"kill-emacs" (0x28be94)
"save-buffers-kill-emacs" (0x28c1a4)
"save-buffers-kill-terminal" (0x28c4f4)
"call-interactively" (0x28c7a4)
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-03 19:58 ` Glenn Morris
2011-11-03 21:05 ` Ken Brown
@ 2011-11-03 21:57 ` Eli Zaretskii
2011-11-04 0:35 ` Stefan Monnier
1 sibling, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-11-03 21:57 UTC (permalink / raw)
To: Glenn Morris; +Cc: 9943
> From: Glenn Morris <rgm@gnu.org>
> Cc: martin rudalics <rudalics@gmx.at>, 9943@debbugs.gnu.org
> Date: Thu, 03 Nov 2011 15:58:11 -0400
>
> Eli Zaretskii wrote:
>
> > I fixed this for w32 (revision 106273 on the trunk). I think the same
> > problem can happen on X, but I cannot run Emacs on X where I'm typing
> > this. Could someone please try the recipe on X and see if the same
> > problem happens there? It could matter which toolkit was used to
> > build Emacs, so please tell which toolkit you are using. TIA.
>
> Lucid toolkit:
>
> Breakpoint 1, abort () at emacs.c:386
> 386 kill (getpid (), SIGABRT);
> (gdb) bt full
> #0 abort () at emacs.c:386
> No locals.
> #1 0x0000000000414ac5 in check_glyph_memory () at dispnew.c:2370
> tail = 12777890
> frame = 17795205
> #2 0x0000000000557bed in shut_down_emacs (sig=0, no_x=0, stuff=12777890)
> at emacs.c:2102
Thanks, I installed the same fix in xfns.c.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-03 21:05 ` Ken Brown
@ 2011-11-03 21:59 ` Eli Zaretskii
2011-11-05 12:26 ` Jan Djärv
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-11-03 21:59 UTC (permalink / raw)
To: Ken Brown; +Cc: 9943
> Date: Thu, 03 Nov 2011 17:05:45 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: Eli Zaretskii <eliz@gnu.org>, 9943@debbugs.gnu.org
>
> On 11/3/2011 3:58 PM, Glenn Morris wrote:
> > Eli Zaretskii wrote:
> >
> >> I fixed this for w32 (revision 106273 on the trunk). I think the same
> >> problem can happen on X, but I cannot run Emacs on X where I'm typing
> >> this. Could someone please try the recipe on X and see if the same
> >> problem happens there? It could matter which toolkit was used to
> >> build Emacs, so please tell which toolkit you are using. TIA.
> >
> > Lucid toolkit:
>
> [...]
>
> Eli,
>
> I don't know if you need results from a second toolkit, but here's what
> I get with gtk:
>
> (gdb) bt full
> #0 abort () at emacs.c:386
> No locals.
> #1 0x00404781 in check_glyph_memory () at dispnew.c:2370
> tail = 8775706
> frame = -2147299323
> #2 0x005149e8 in shut_down_emacs (sig=0, no_x=0, stuff=8775706)
> at emacs.c:2102
Thanks, I installed a fix.
nsfns.m has a similar problem, but x-create-frame there doesn't have
an unwind-protect function to add a similar change. Can someone test
this recipe on a Mac?
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-03 21:57 ` Eli Zaretskii
@ 2011-11-04 0:35 ` Stefan Monnier
2011-11-04 9:12 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Stefan Monnier @ 2011-11-04 0:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9943
> Thanks, I installed the same fix in xfns.c.
All this code duplication is really a bore. We should really create
a new file (say "dispfns.c") where we can consolidate common code from
xfns, nsfns, and w32fns. A good start would be that whenever we have to
make the same fix at all 3 places, we rearrange the code locally to call
a new function in dispfns.c which would receive the common part where
the fix can then be applied.
Stefan
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-04 0:35 ` Stefan Monnier
@ 2011-11-04 9:12 ` Eli Zaretskii
2011-11-04 16:53 ` Glenn Morris
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-11-04 9:12 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 9943
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Glenn Morris <rgm@gnu.org>, 9943@debbugs.gnu.org
> Date: Thu, 03 Nov 2011 20:35:04 -0400
>
> > Thanks, I installed the same fix in xfns.c.
>
> All this code duplication is really a bore. We should really create
> a new file (say "dispfns.c") where we can consolidate common code from
> xfns, nsfns, and w32fns.
I agree. How about filing a wishlist bug for that?
> A good start would be that whenever we have to make the same fix at
> all 3 places, we rearrange the code locally to call a new function
> in dispfns.c which would receive the common part where the fix can
> then be applied.
The problem is that the code is similar, but different, with
platform-specific fragments sprinkled all over. So refactoring it
into a single implementation is not a trivial job. Making a function
out of every common fragment is not the best idea, since it will
typically depend on local and static variables and static functions.
Quite to the opposite: extracting platform-specific snippets into
functions with platform-specific implementation might be a better
idea. Or not, it all depends on careful analysis that should be done
as a prerequisite to deciding which way is better.
So it's not an easy editing job, even if you want to approach this
incrementally. I think it's rather a refactoring project that should
be taken as a whole, or maybe as a few large sub-jobs.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-04 9:12 ` Eli Zaretskii
@ 2011-11-04 16:53 ` Glenn Morris
0 siblings, 0 replies; 14+ messages in thread
From: Glenn Morris @ 2011-11-04 16:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9943
Eli Zaretskii wrote:
>> All this code duplication is really a bore. We should really create
>> a new file (say "dispfns.c") where we can consolidate common code from
>> xfns, nsfns, and w32fns.
>
> I agree. How about filing a wishlist bug for that?
I think http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4402#36 covers it.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-03 21:59 ` Eli Zaretskii
@ 2011-11-05 12:26 ` Jan Djärv
2011-11-05 13:18 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Jan Djärv @ 2011-11-05 12:26 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9943
Hello.
3 nov 2011 kl. 22:59 skrev Eli Zaretskii:
>> Date: Thu, 03 Nov 2011 17:05:45 -0400
>> From: Ken Brown <kbrown@cornell.edu>
>> CC: Eli Zaretskii <eliz@gnu.org>, 9943@debbugs.gnu.org
>>
>> On 11/3/2011 3:58 PM, Glenn Morris wrote:
>>> Eli Zaretskii wrote:
>>>
>>>> I fixed this for w32 (revision 106273 on the trunk). I think the same
>>>> problem can happen on X, but I cannot run Emacs on X where I'm typing
>>>> this. Could someone please try the recipe on X and see if the same
>>>> problem happens there? It could matter which toolkit was used to
>>>> build Emacs, so please tell which toolkit you are using. TIA.
>>>
>>> Lucid toolkit:
>>
>> [...]
>>
>> Eli,
>>
>> I don't know if you need results from a second toolkit, but here's what
>> I get with gtk:
>>
>> (gdb) bt full
>> #0 abort () at emacs.c:386
>> No locals.
>> #1 0x00404781 in check_glyph_memory () at dispnew.c:2370
>> tail = 8775706
>> frame = -2147299323
>> #2 0x005149e8 in shut_down_emacs (sig=0, no_x=0, stuff=8775706)
>> at emacs.c:2102
>
> Thanks, I installed a fix.
I don't think it was quite correct.
In x-create-frame terminal->reference_count gets incremented before record_unwind_protect, but it is not decremented in case the unwind protect function is called.
I don't know if w32 has the same problem?
Also, in w32term.c, image_cache_refcount is assigned before init_frame_faces is called, but in xterm.c, this is reversed. Indeed, turning on GLYPH_DEBUG and recreating this bug causes an assert violation in unwind_create_frame.
I don't know about w32, but on ns and X, accessing FRAME_IMAGE_CACHE (f)->refcount before calling init_frame_faces causes a segmentation violation, as FRAME_IMAGE_CACHE (f) is NULL.
Also, there is a typo in the comment to unwind_create_frame, x_create_top_frame should be ..._tip_frame. This may have been an old thing.
I fixed these issues on X and ns (I hope :-).
>
> nsfns.m has a similar problem, but x-create-frame there doesn't have
> an unwind-protect function to add a similar change. Can someone test
> this recipe on a Mac?
The same bug was present there, but is fixed now.
Jan D.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-05 12:26 ` Jan Djärv
@ 2011-11-05 13:18 ` Eli Zaretskii
2011-11-05 15:50 ` Jan Djärv
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-11-05 13:18 UTC (permalink / raw)
To: Jan Djärv; +Cc: 9943
> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 5 Nov 2011 13:26:08 +0100
> Cc: Ken Brown <kbrown@cornell.edu>,
> 9943@debbugs.gnu.org
>
> >> #0 abort () at emacs.c:386
> >> No locals.
> >> #1 0x00404781 in check_glyph_memory () at dispnew.c:2370
> >> tail = 8775706
> >> frame = -2147299323
> >> #2 0x005149e8 in shut_down_emacs (sig=0, no_x=0, stuff=8775706)
> >> at emacs.c:2102
> >
> > Thanks, I installed a fix.
>
> I don't think it was quite correct.
Thanks for double-checking it.
> In x-create-frame terminal->reference_count gets incremented before record_unwind_protect, but it is not decremented in case the unwind protect function is called.
Isn't it safer (from the POV of potentially destabilizing Emacs during
a pretest) to leave the increment where it was, and decrement it in the
unwind protect function?
> Also, in w32term.c, image_cache_refcount is assigned before init_frame_faces is called, but in xterm.c, this is reversed. Indeed, turning on GLYPH_DEBUG and recreating this bug causes an assert violation in unwind_create_frame.
An old bug, now fixed. Thanks. (Looks like not many people have
GLYPH_DEBUG turned on these days.)
> I don't know about w32, but on ns and X, accessing FRAME_IMAGE_CACHE (f)->refcount before calling init_frame_faces causes a segmentation violation, as FRAME_IMAGE_CACHE (f) is NULL.
Even if it doesn't, it doesn't hurt to add the test in w32fns.c as
well.
> Also, there is a typo in the comment to unwind_create_frame, x_create_top_frame should be ..._tip_frame. This may have been an old thing.
>
> I fixed these issues on X and ns (I hope :-).
Thanks.
> > nsfns.m has a similar problem, but x-create-frame there doesn't have
> > an unwind-protect function to add a similar change. Can someone test
> > this recipe on a Mac?
>
> The same bug was present there, but is fixed now.
Thanks.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-05 13:18 ` Eli Zaretskii
@ 2011-11-05 15:50 ` Jan Djärv
2011-11-05 16:27 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Jan Djärv @ 2011-11-05 15:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 9943
5 nov 2011 kl. 14:18 skrev Eli Zaretskii:
>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Sat, 5 Nov 2011 13:26:08 +0100
>> Cc: Ken Brown <kbrown@cornell.edu>,
>> 9943@debbugs.gnu.org
>>
>
>> In x-create-frame terminal->reference_count gets incremented before record_unwind_protect, but it is not decremented in case the unwind protect function is called.
>
> Isn't it safer (from the POV of potentially destabilizing Emacs during
> a pretest) to leave the increment where it was, and decrement it in the
> unwind protect function?
>
Maybe, but I rather leave it as is, so it mirrors the dpyinfo->reference_count usage.
Jan D.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-05 15:50 ` Jan Djärv
@ 2011-11-05 16:27 ` Eli Zaretskii
2011-11-07 21:05 ` Glenn Morris
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2011-11-05 16:27 UTC (permalink / raw)
To: Jan Djärv; +Cc: 9943
> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Sat, 5 Nov 2011 16:50:33 +0100
> Cc: kbrown@cornell.edu,
> 9943@debbugs.gnu.org
>
>
> >> In x-create-frame terminal->reference_count gets incremented before record_unwind_protect, but it is not decremented in case the unwind protect function is called.
> >
> > Isn't it safer (from the POV of potentially destabilizing Emacs during
> > a pretest) to leave the increment where it was, and decrement it in the
> > unwind protect function?
> >
>
> Maybe, but I rather leave it as is, so it mirrors the dpyinfo->reference_count usage.
<Shrug> OK, I made w32fns.c do the same.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#9943: 24.0.91; Abort in check_glyph_memory
2011-11-05 16:27 ` Eli Zaretskii
@ 2011-11-07 21:05 ` Glenn Morris
0 siblings, 0 replies; 14+ messages in thread
From: Glenn Morris @ 2011-11-07 21:05 UTC (permalink / raw)
To: 9943-done
Version: 24.0.92
IIUC, this is now fixed on all affected platforms.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-11-07 21:05 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-11-03 9:17 bug#9943: 24.0.91; Abort in check_glyph_memory martin rudalics
2011-11-03 19:08 ` Eli Zaretskii
2011-11-03 19:58 ` Glenn Morris
2011-11-03 21:05 ` Ken Brown
2011-11-03 21:59 ` Eli Zaretskii
2011-11-05 12:26 ` Jan Djärv
2011-11-05 13:18 ` Eli Zaretskii
2011-11-05 15:50 ` Jan Djärv
2011-11-05 16:27 ` Eli Zaretskii
2011-11-07 21:05 ` Glenn Morris
2011-11-03 21:57 ` Eli Zaretskii
2011-11-04 0:35 ` Stefan Monnier
2011-11-04 9:12 ` Eli Zaretskii
2011-11-04 16:53 ` Glenn Morris
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).