bug#15565: 24.3.50; emacs_backtrace

bug#15565: 24.3.50; emacs_backtrace

[Dani Moncayo]

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 eliz@gnu.org-20131008190640-26yo36k2fe8lgk8i
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

bug#15565: 24.3.50; emacs_backtrace

[Eli Zaretskii]

> Date: Tue, 8 Oct 2013 22:04:38 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> 
> 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.

bug#15565: 24.3.50; emacs_backtrace

[Dani Moncayo]

>> 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.

My build environment hasn't changed since the last time I bootstrapped
(2013-09-30).  (at least I'm not aware of any change)

I may provide any extra necessary info for tracking this problem down.

TIA.

-- 
Dani Moncayo

bug#15565: 24.3.50; emacs_backtrace

[Eli Zaretskii]

> Date: Tue, 8 Oct 2013 22:53:04 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 15565@debbugs.gnu.org
> 
> >> 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.)