* 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 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: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
* 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: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
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 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.