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.