From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: 10296@debbugs.gnu.org
Subject: bug#10296: 24.0.92; check_glyph_memory still aborting
Date: Thu, 15 Dec 2011 14:14:39 +0200 [thread overview]
Message-ID: <8339cm2frk.fsf@gnu.org> (raw)
In-Reply-To: <4EE8548C.9030901@gmx.at>
> 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.
next prev parent reply other threads:[~2011-12-15 12:14 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-14 7:47 bug#10296: 24.0.92; check_glyph_memory still aborting martin rudalics
2011-12-14 8:28 ` Eli Zaretskii
2011-12-14 9:42 ` martin rudalics
2011-12-14 10:13 ` Eli Zaretskii
2011-12-14 10:46 ` martin rudalics
2011-12-14 12:26 ` Juanma Barranquero
2011-12-14 13:34 ` martin rudalics
2011-12-15 12:14 ` Eli Zaretskii [this message]
2011-12-16 9:56 ` Martin Rudalics
2011-12-16 11:24 ` Eli Zaretskii
2015-12-25 23:12 ` Lars Ingebrigtsen
2016-12-07 19:21 ` Glenn Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8339cm2frk.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=10296@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).