GNU bug report logs - #9943
24.0.91; Abort in check_glyph_memory

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9943 in the body.
You can then email your comments to 9943 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.91; Abort in check_glyph_memory
Date: Thu, 03 Nov 2011 10:17:00 +0100

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'

Message #10 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 9943 <at> debbugs.gnu.org
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
Date: Thu, 03 Nov 2011 21:08:12 +0200

> Date: Thu, 03 Nov 2011 10:17:00 +0100
> From: martin rudalics <rudalics <at> 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.

Message #13 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, 9943 <at> debbugs.gnu.org
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
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
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)

Message #16 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 9943 <at> debbugs.gnu.org
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
Date: Thu, 03 Nov 2011 17:05:45 -0400

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)

Message #19 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: rudalics <at> gmx.at, 9943 <at> debbugs.gnu.org
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
Date: Thu, 03 Nov 2011 23:57:36 +0200

> From: Glenn Morris <rgm <at> gnu.org>
> Cc: martin rudalics <rudalics <at> gmx.at>,  9943 <at> 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.

Message #22 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: rgm <at> gnu.org, 9943 <at> debbugs.gnu.org
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
Date: Thu, 03 Nov 2011 23:59:07 +0200

> Date: Thu, 03 Nov 2011 17:05:45 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: Eli Zaretskii <eliz <at> gnu.org>, 9943 <at> 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?

Message #25 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 9943 <at> debbugs.gnu.org
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
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.  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

Message #28 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: rgm <at> gnu.org, 9943 <at> debbugs.gnu.org
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
Date: Fri, 04 Nov 2011 11:12:13 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Glenn Morris <rgm <at> gnu.org>,  9943 <at> 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.

Message #31 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9943 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
Date: Fri, 04 Nov 2011 12:53:50 -0400

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.

Message #34 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9943 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
Date: Sat, 5 Nov 2011 13:26:08 +0100

Hello.

3 nov 2011 kl. 22:59 skrev Eli Zaretskii:

>> Date: Thu, 03 Nov 2011 17:05:45 -0400
>> From: Ken Brown <kbrown <at> cornell.edu>
>> CC: Eli Zaretskii <eliz <at> gnu.org>, 9943 <at> 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.

Message #37 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 9943 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
Date: Sat, 05 Nov 2011 15:18:11 +0200

> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Sat, 5 Nov 2011 13:26:08 +0100
> Cc: Ken Brown <kbrown <at> cornell.edu>,
>  9943 <at> 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.

Message #40 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9943 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
Date: Sat, 5 Nov 2011 16:50:33 +0100

5 nov 2011 kl. 14:18 skrev Eli Zaretskii:

>> From: Jan Djärv <jan.h.d <at> swipnet.se>
>> Date: Sat, 5 Nov 2011 13:26:08 +0100
>> Cc: Ken Brown <kbrown <at> cornell.edu>,
>> 9943 <at> 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.

Message #43 received at 9943 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 9943 <at> debbugs.gnu.org, kbrown <at> cornell.edu
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
Date: Sat, 05 Nov 2011 18:27:44 +0200

> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Sat, 5 Nov 2011 16:50:33 +0100
> Cc: kbrown <at> cornell.edu,
>  9943 <at> 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.

Message #48 received at 9943-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 9943-done <at> debbugs.gnu.org
Subject: Re: bug#9943: 24.0.91; Abort in check_glyph_memory
Date: Mon, 07 Nov 2011 16:05:44 -0500

Version: 24.0.92

IIUC, this is now fixed on all affected platforms.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.