--- Begin Message ---
Subject: |
24.3.50; emacs_backtrace |
Date: |
Tue, 8 Oct 2013 22:04:38 +0200 |
I've just bootstrapped the latest trunk, and it crashes very easily.
For example:
emacs -Q
C-h r
This is the backtrace I get:
??
??:0
??
??:0
w32_backtrace at w32fns.c:7965
emacs_abort at w32fns.c:7997
terminate_due_to_signal at emacs.c:376
die at alloc.c:6605
x_free_gc at xfaces.c:632
free_realized_face at xfaces.c:4049
free_realized_faces at xfaces.c:4221
free_all_realized_faces at xfaces.c:4255
init_iterator at xdisp.c:2665
resize_mini_window at xdisp.c:10471
display_echo_area_1 at xdisp.c:10357
with_echo_area_buffer at xdisp.c:10147
display_echo_area at xdisp.c:10327
echo_area_display at xdisp.c:10831
message3_nolog at xdisp.c:9828
message3 at xdisp.c:9774
message1 at xdisp.c:9847
Fmessage at editfns.c:3442
Ffuncall at eval.c:2770
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3023
Ffuncall at eval.c:2838
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3023
Ffuncall at eval.c:2838
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3023
Ffuncall at eval.c:2838
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3023
Ffuncall at eval.c:2838
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3023
Ffuncall at eval.c:2838
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3023
Ffuncall at eval.c:2838
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3023
Ffuncall at eval.c:2838
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3023
Ffuncall at eval.c:2838
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3023
Ffuncall at eval.c:2838
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3023
Ffuncall at eval.c:2838
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:3023
Ffuncall at eval.c:2838
apply1 at eval.c:2555
Fcall_interactively at callint.c:378
Ffuncall at eval.c:2796
exec_byte_code at bytecode.c:919
funcall_lambda at eval.c:2957
Ffuncall at eval.c:2838
call1 at eval.c:2588
command_loop_1 at keyboard.c:1561
internal_condition_case at eval.c:1331
command_loop_2 at keyboard.c:1162
??
??:0
In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
of 2013-10-08 on LEG570
Bzr revision: 114584 address@hidden
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'
Important settings:
value of $LANG: ENU
locale-coding-system: cp1252
default enable-multibyte-characters: t
--
Dani Moncayo
--- End Message ---
--- Begin Message ---
Subject: |
Re: bug#15565: 24.3.50; emacs_backtrace |
Date: |
Wed, 09 Oct 2013 17:58:43 +0300 |
> Date: Tue, 8 Oct 2013 22:53:04 +0200
> From: Dani Moncayo <address@hidden>
> Cc: address@hidden
>
> >> I've just bootstrapped the latest trunk, and it crashes very easily.
> >> For example:
> >> emacs -Q
> >> C-h r
> >>
> >> This is the backtrace I get:
> >
> > Doesn't happen here, sorry.
>
> Ok, I've tried to bootstrap again the latest trunk (now at revno
> 114585), and I get the same crash with the same backtrace.
I've succeeded in reproducing this. To get hit by the bug, you need
(a) to compile with GLYPH_DEBUG=1, and (b) use a new enough compiler
that supports a non-trivial definition of 'assume'.
The problem is that 'eassert' can no longer take expressions that have
side effects, because it evaluates them twice!
I fixed this particular assertion violation in trunk revision 114590,
but I think we had better fixed 'eassert' to not have this nasty
misfeature.
(I guess no one who works on Unix compiles with GLYPH_DEBUG=1, because
the same problem was present on X. That's too bad, since
GLYPH_DEBUG=1 is a valuable feature for weeding out bugs sooner rather
than later.)
--- End Message ---