GNU bug report logs - #10296
24.0.92; check_glyph_memory still aborting

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 10296 in the body.
You can then email your comments to 10296 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.92; check_glyph_memory still aborting
Date: Wed, 14 Dec 2011 08:47:24 +0100

Bugs #8775 and #9943 seem to be still around.  The scenario for #9943
needs one additional line to trigger here on

GNU Emacs 24.0.92.1 (i386-mingw-nt5.1.2600)
 of 2011-12-13 on NESTOR

So with emacs -Q evaluating

(progn
  (setq default-frame-alist (cons '(height . 0.2) default-frame-alist))
  (setq debug-on-error t))

and subsequently doing

C-x 5 2
C-x C-c

gets me the following backtrace:

(gdb) bt
#0  w32_abort () at w32fns.c:7191
#1  0x01061dbd in check_glyph_memory () at dispnew.c:2399
#2  0x01002eaa in shut_down_emacs (sig=0, no_x=0, stuff=50145306)
    at emacs.c:2104
#3  0x01002da6 in Fkill_emacs (arg=50145306) at emacs.c:2016
#4  0x010226cf in Ffuncall (nargs=1, args=0x82e050) at eval.c:2986
#5  0x010c888b in exec_byte_code (bytestr=19226889, vector=19226909,
    maxdepth=20, args_template=50145306, nargs=0, args=0x0) at bytecode.c:785
#6  0x01022fab in funcall_lambda (fun=19226861, nargs=1, arg_vector=0x82e2a4)
    at eval.c:3217
#7  0x010228ec in Ffuncall (nargs=2, args=0x82e2a0) at eval.c:3035
#8  0x010c888b in exec_byte_code (bytestr=19227121, vector=19227141,
    maxdepth=12, args_template=50145306, nargs=0, args=0x0) at bytecode.c:785
#9  0x01022fab in funcall_lambda (fun=19227093, nargs=1, arg_vector=0x82e534)
    at eval.c:3217
#10 0x010228ec in Ffuncall (nargs=2, args=0x82e530) at eval.c:3035
#11 0x010c7c5e in Fcall_interactively (function=50991226,
    record_flag=50145306, keys=50166533) at callint.c:859
#12 0x01022723 in Ffuncall (nargs=4, args=0x82e7c0) at eval.c:2993
#13 0x01022121 in call3 (fn=50265450, arg1=50991226, arg2=50145306,
    arg3=50145306) at eval.c:2786
#14 0x01013171 in Fcommand_execute (cmd=50991226, record_flag=50145306,
    keys=50145306, special=50145306) at keyboard.c:10302
#15 0x01005047 in command_loop_1 () at keyboard.c:1571
#16 0x0101fd4b in internal_condition_case (bfun=0x1004977 <command_loop_1>,
    handlers=50203034, hfun=0x1004363 <cmd_error>) at eval.c:1499
#17 0x010046d3 in command_loop_2 (ignore=50145306) at keyboard.c:1159
#18 0x0101f821 in internal_catch (tag=50250186,
    func=0x10046b0 <command_loop_2>, arg=50145306) at eval.c:1256
#19 0x0100463a in command_loop () at keyboard.c:1124
#20 0x01003f99 in recursive_edit_1 () at keyboard.c:758
#21 0x010040e3 in Frecursive_edit () at keyboard.c:822
#22 0x010226b4 in Ffuncall (nargs=1, args=0x82ebc0) at eval.c:2983
#23 0x010c888b in exec_byte_code (bytestr=56207793, vector=50219013,
    maxdepth=116, args_template=50145306, nargs=0, args=0x0) at bytecode.c:785
#24 0x01022fab in funcall_lambda (fun=50894437, nargs=2, arg_vector=0x82ee74)
    at eval.c:3217
#25 0x010228ec in Ffuncall (nargs=3, args=0x82ee70) at eval.c:3035
#26 0x01021c2f in Fapply (nargs=2, args=0x82ef10) at eval.c:2491
#27 0x0102204c in apply1 (fn=50250354, arg=54707486) at eval.c:2729
#28 0x0101df43 in call_debugger (arg=54707486) at eval.c:221
#29 0x0102078f in maybe_call_debugger (conditions=19000270, sig=50203082,
    data=54707270) at eval.c:1914
#30 0x01020351 in Fsignal (error_symbol=50203082, data=54707270)
    at eval.c:1736
#31 0x0102044c in xsignal (error_symbol=50203082, data=54707270)
    at eval.c:1770
#32 0x010204b2 in xsignal2 (error_symbol=50203082, arg1=50203610,
    arg2=50132223) at eval.c:1791
#33 0x010170d1 in wrong_type_argument (predicate=2, value=56164352)
    at data.c:111
#34 0x011a8fc4 in x_figure_window_size (f=0x3202a00, parms=54710358,
    toolbar_p=1) at frame.c:4043
#35 0x01174508 in Fx_create_frame (parameters=54710358) at w32fns.c:4279
#36 0x010226cf in Ffuncall (nargs=2, args=0x82f210) at eval.c:2986
#37 0x010c888b in exec_byte_code (bytestr=19255697, vector=19255717,
    maxdepth=16, args_template=50145306, nargs=0, args=0x0) at bytecode.c:785
#38 0x01022fab in funcall_lambda (fun=19255661, nargs=1, arg_vector=0x82f454)
    at eval.c:3217
#39 0x010228ec in Ffuncall (nargs=2, args=0x82f450) at eval.c:3035
#40 0x010c888b in exec_byte_code (bytestr=19582321, vector=19582341,
    maxdepth=20, args_template=50145306, nargs=0, args=0x0) at bytecode.c:785
#41 0x01022fab in funcall_lambda (fun=19582293, nargs=0, arg_vector=0x82f6a4)
    at eval.c:3217
#42 0x010228ec in Ffuncall (nargs=1, args=0x82f6a0) at eval.c:3035
#43 0x010c888b in exec_byte_code (bytestr=19582097, vector=19582117,
    maxdepth=8, args_template=50145306, nargs=0, args=0x0) at bytecode.c:785
#44 0x01022fab in funcall_lambda (fun=19582069, nargs=0, arg_vector=0x82f924)
    at eval.c:3217
#45 0x010228ec in Ffuncall (nargs=1, args=0x82f920) at eval.c:3035
#46 0x01022015 in apply1 (fn=53869098, arg=50145306) at eval.c:2722
#47 0x010c6375 in Fcall_interactively (function=53869098,
    record_flag=50145306, keys=50166533) at callint.c:379
#48 0x01022723 in Ffuncall (nargs=4, args=0x82fb90) at eval.c:2993
#49 0x01022121 in call3 (fn=50265450, arg1=53869098, arg2=50145306,
    arg3=50145306) at eval.c:2786
#50 0x01013171 in Fcommand_execute (cmd=53869098, record_flag=50145306,
    keys=50145306, special=50145306) at keyboard.c:10302
#51 0x01005047 in command_loop_1 () at keyboard.c:1571
#52 0x0101fd4b in internal_condition_case (bfun=0x1004977 <command_loop_1>,
    handlers=50203034, hfun=0x1004363 <cmd_error>) at eval.c:1499
#53 0x010046d3 in command_loop_2 (ignore=50145306) at keyboard.c:1159
#54 0x0101f821 in internal_catch (tag=50201058,
    func=0x10046b0 <command_loop_2>, arg=50145306) at eval.c:1256
#55 0x0100468b in command_loop () at keyboard.c:1138
#56 0x01003f99 in recursive_edit_1 () at keyboard.c:758
#57 0x010040e3 in Frecursive_edit () at keyboard.c:822
#58 0x01002763 in main (argc=2, argv=0xa327e0) at emacs.c:1709

Lisp Backtrace:
"kill-emacs" (0x82e054)
"save-buffers-kill-emacs" (0x82e2a4)
"save-buffers-kill-terminal" (0x82e534)
"call-interactively" (0x82e7c4)
"recursive-edit" (0x82ebc4)
"debug" (0x82ee74)
"x-create-frame" (0x82f214)
"x-create-frame-with-faces" (0x82f454)
"make-frame" (0x82f6a4)
"make-frame-command" (0x82f924)
"call-interactively" (0x82fb94)
(gdb)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 10296 <at> debbugs.gnu.org
Subject: Re: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Wed, 14 Dec 2011 03:28:55 -0500

> Date: Wed, 14 Dec 2011 08:47:24 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> 
> Bugs #8775 and #9943 seem to be still around.  The scenario for #9943
> needs one additional line to trigger here on

Thanks, but why did you file a new bug? why not write to an address of
#9943 instead?

> So with emacs -Q evaluating
> 
> (progn
>    (setq default-frame-alist (cons '(height . 0.2) default-frame-alist))
>    (setq debug-on-error t))
> 
> and subsequently doing
> 
> C-x 5 2
> C-x C-c
> 
> gets me the following backtrace:
> 
> (gdb) bt
> #0  w32_abort () at w32fns.c:7191
> #1  0x01061dbd in check_glyph_memory () at dispnew.c:2399
> #2  0x01002eaa in shut_down_emacs (sig=0, no_x=0, stuff=50145306)
>      at emacs.c:2104

I will look into this in a few days if no one beats me to it.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10296 <at> debbugs.gnu.org
Subject: Re: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Wed, 14 Dec 2011 10:42:08 +0100

> Thanks, but why did you file a new bug? why not write to an address of
> #9943 instead?

Because I didn't know whether I had to unarchive #9943 first.
Which is the precise address I'd have to use (if it matters)?

> I will look into this in a few days if no one beats me to it.

Thanks, martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 10296 <at> debbugs.gnu.org
Subject: Re: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Wed, 14 Dec 2011 05:13:33 -0500

> Date: Wed, 14 Dec 2011 10:42:08 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 10296 <at> debbugs.gnu.org
> 
> Which is the precise address I'd have to use (if it matters)?

9943 <at> debbugs.gnu.org for adding to the bug report,
control <at> debbugs.gnu.org to unarchive.  It's all in
admin/notes/bugtracker.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10296 <at> debbugs.gnu.org
Subject: Re: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Wed, 14 Dec 2011 11:46:51 +0100

> 9943 <at> debbugs.gnu.org for adding to the bug report,

This works only if the bug hasn't been archived yet, I presume.

> control <at> debbugs.gnu.org to unarchive.

Does this want a subject line?  The body would be

unarchive 9943

then.  Or is

reopen 9943

better?

> It's all in
> admin/notes/bugtracker.

I'll read that now.

Thanks, martin

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 10296 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Wed, 14 Dec 2011 13:26:48 +0100

On Wed, Dec 14, 2011 at 11:46, martin rudalics <rudalics <at> gmx.at> wrote:

> Does this want a subject line?

It's not required.

> The body would be
>
> unarchive 9943
>
> then.  Or is
>
> reopen 9943
>
> better?

"You can still send mail to a bug after it is closed.  After 28 days with
no activity, the bug is archived, at which point no more changes can
be made.  If you try to send mail to the bug after that (or merge with
it), it will be rejected.  To make any changes, you must unarchive it first:"

So you can send an e-mail to control <at> debbugs.gnu.org containing.

  unarchive 9943
  reopen 9943
  quit

and it should suffice.

    Juanma

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

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 10296 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Wed, 14 Dec 2011 14:34:57 +0100

> So you can send an e-mail to control <at> debbugs.gnu.org containing.
>
>   unarchive 9943
>   reopen 9943
>   quit
>
> and it should suffice.

I'll try that next time.

Thanks, martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 10296 <at> debbugs.gnu.org
Subject: Re: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Thu, 15 Dec 2011 14:14:39 +0200

> Date: Wed, 14 Dec 2011 08:47:24 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> 
> Bugs #8775 and #9943 seem to be still around.  The scenario for #9943
> needs one additional line to trigger here on
> 
> GNU Emacs 24.0.92.1 (i386-mingw-nt5.1.2600)
>   of 2011-12-13 on NESTOR
> 
> So with emacs -Q evaluating
> 
> (progn
>    (setq default-frame-alist (cons '(height . 0.2) default-frame-alist))
>    (setq debug-on-error t))
> 
> and subsequently doing
> 
> C-x 5 2
> C-x C-c
> 
> gets me the following backtrace:
> 
> (gdb) bt
> #0  w32_abort () at w32fns.c:7191
> #1  0x01061dbd in check_glyph_memory () at dispnew.c:2399
> #2  0x01002eaa in shut_down_emacs (sig=0, no_x=0, stuff=50145306)
>      at emacs.c:2104

This is not the same bug.  I'm not even sure it's a bug.  The problem
is that, by setting debug-on-error, you caused the debugger to be
entered _before_ running the unwind-protect function set up by
x-create-frame, which takes care of releasing the glyph matrices
allocated for the new frame whose creation fails due the wrong value
of the `height' parameter.  Look at the backtrace:

  #2  0x01002eaa in shut_down_emacs (sig=0, no_x=0, stuff=50145306)
       at emacs.c:2104
  #3  0x01002da6 in Fkill_emacs (arg=50145306) at emacs.c:2016
  ...
  #14 0x01013171 in Fcommand_execute (cmd=50991226, record_flag=50145306,
       keys=50145306, special=50145306) at keyboard.c:10302
  #15 0x01005047 in command_loop_1 () at keyboard.c:1571
  #16 0x0101fd4b in internal_condition_case (bfun=0x1004977 <command_loop_1>,
       handlers=50203034, hfun=0x1004363 <cmd_error>) at eval.c:1499
  #17 0x010046d3 in command_loop_2 (ignore=50145306) at keyboard.c:1159
  #18 0x0101f821 in internal_catch (tag=50250186,
       func=0x10046b0 <command_loop_2>, arg=50145306) at eval.c:1256
  #19 0x0100463a in command_loop () at keyboard.c:1124
  #20 0x01003f99 in recursive_edit_1 () at keyboard.c:758
  #21 0x010040e3 in Frecursive_edit () at keyboard.c:822
  ...
  #28 0x0101df43 in call_debugger (arg=54707486) at eval.c:221
  #29 0x0102078f in maybe_call_debugger (conditions=19000270, sig=50203082,
       data=54707270) at eval.c:1914
  #30 0x01020351 in Fsignal (error_symbol=50203082, data=54707270)
       at eval.c:1736
  #31 0x0102044c in xsignal (error_symbol=50203082, data=54707270)
       at eval.c:1770
  #32 0x010204b2 in xsignal2 (error_symbol=50203082, arg1=50203610,
       arg2=50132223) at eval.c:1791
  #33 0x010170d1 in wrong_type_argument (predicate=2, value=56164352)
       at data.c:111
  #34 0x011a8fc4 in x_figure_window_size (f=0x3202a00, parms=54710358,
       toolbar_p=1) at frame.c:4043
  #35 0x01174508 in Fx_create_frame (parameters=54710358) at w32fns.c:4279

As you see, x-create-frame threw a signal, which called the debugger,
which entered the recursive edit, and then Emacs was shut down from
the recursive editing level.  When `abort' is being called, you can
see in the debugger that command_loop_level is 1, not zero.

If you type "C-]" to exit the debugger, and then "C-x C-c", then Emacs
exits normally without aborting.  I verified that unwind_create_frame
_is_ called in that case.

We never run the unwind-protect functions when Emacs is shut down from
a level > 0.  I don't know if this is by design (otherwise, you might
be unable to exit in an orderly fashion in some case, perhaps?).  Does
anyone know?

If this is by design, I could easily avoid this abort when
command_loop_level is non-zero, if that's TRT to do.

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

From: "Martin Rudalics" <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 10296 <at> debbugs.gnu.org
Subject: Re: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Fri, 16 Dec 2011 10:56:54 +0100

> This is not the same bug.

As you noticed I _was_ reluctant to reopen the old bug  ;-) 

> If you type "C-]" to exit the debugger, and then "C-x C-c", then Emacs
> exits normally without aborting.

Yes.  I had tried that when looking for a simpler recipe.

> If this is by design, I could easily avoid this abort when
> command_loop_level is non-zero, if that's TRT to do.

IMHO the fact that the abort dialogue pops up is not TRT.

martin

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Martin Rudalics <rudalics <at> gmx.at>
Cc: 10296 <at> debbugs.gnu.org
Subject: Re: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Fri, 16 Dec 2011 13:24:25 +0200

> Cc: 10296 <at> debbugs.gnu.org
> Date: Fri, 16 Dec 2011 10:56:54 +0100
> From: "Martin Rudalics" <rudalics <at> gmx.at>
> 
> > If this is by design, I could easily avoid this abort when
> > command_loop_level is non-zero, if that's TRT to do.
> 
> IMHO the fact that the abort dialogue pops up is not TRT.

Of course.  The question is whether it's TRT to avoid the abort by
ignoring the results of checking glyph memory, solely because we are
exiting from a recursive level > 0.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Martin Rudalics" <rudalics <at> gmx.at>
Cc: 10296 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Sat, 26 Dec 2015 00:12:48 +0100

"Martin Rudalics" <rudalics <at> gmx.at> writes:

>> This is not the same bug.
>
> As you noticed I _was_ reluctant to reopen the old bug  ;-) 
>
>> If you type "C-]" to exit the debugger, and then "C-x C-c", then Emacs
>> exits normally without aborting.
>
> Yes.  I had tried that when looking for a simpler recipe.
>
>> If this is by design, I could easily avoid this abort when
>> command_loop_level is non-zero, if that's TRT to do.
>
> IMHO the fact that the abort dialogue pops up is not TRT.

It's unclear what the status of this bug report is...  It's marked as
"moreinfo", but I don't see what info if being requested...

Anyway, is this still an issue?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Glenn Morris <rgm <at> gnu.org>
To: 10296-done <at> debbugs.gnu.org
Subject: Re: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Wed, 07 Dec 2016 14:21:57 -0500

Lars Ingebrigtsen wrote:

> It's unclear what the status of this bug report is...  It's marked as
> "moreinfo", but I don't see what info if being requested...
>
> Anyway, is this still an issue?

One year on, I'm closing this.

Previous Next

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