bug#10296: 24.0.92; check_glyph_memory still aborting

bug#10296: 24.0.92; check_glyph_memory still aborting

[martin rudalics]

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)

bug#10296: 24.0.92; check_glyph_memory still aborting

[Eli Zaretskii]

> Date: Wed, 14 Dec 2011 08:47:24 +0100
> From: martin rudalics <rudalics@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.

bug#10296: 24.0.92; check_glyph_memory still aborting

[martin rudalics]

> 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

bug#10296: 24.0.92; check_glyph_memory still aborting

[Eli Zaretskii]

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

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

bug#10296: 24.0.92; check_glyph_memory still aborting

[martin rudalics]

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

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

 > control@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

bug#10296: 24.0.92; check_glyph_memory still aborting

[Juanma Barranquero]

On Wed, Dec 14, 2011 at 11:46, martin rudalics <rudalics@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@debbugs.gnu.org containing.

  unarchive 9943
  reopen 9943
  quit

and it should suffice.

    Juanma

bug#10296: 24.0.92; check_glyph_memory still aborting

[martin rudalics]

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

I'll try that next time.

Thanks, martin

bug#10296: 24.0.92; check_glyph_memory still aborting

[Eli Zaretskii]

> Date: Wed, 14 Dec 2011 08:47:24 +0100
> From: martin rudalics <rudalics@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.

bug#10296: 24.0.92; check_glyph_memory still aborting

[Martin Rudalics]

> 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

bug#10296: 24.0.92; check_glyph_memory still aborting

[Eli Zaretskii]

> Cc: 10296@debbugs.gnu.org
> Date: Fri, 16 Dec 2011 10:56:54 +0100
> From: "Martin Rudalics" <rudalics@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.

bug#10296: 24.0.92; check_glyph_memory still aborting

[Lars Ingebrigtsen]

"Martin Rudalics" <rudalics@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

bug#10296: 24.0.92; check_glyph_memory still aborting

[Glenn Morris]

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.