GNU bug report logs - #10164
24.0.91; Instant crash enabling linum-mode

Previous Next

Package: emacs;

Reported by: Tim Crews <tim.crews <at> code-affinity.com>

Date: Wed, 30 Nov 2011 05:24:01 UTC

Severity: normal

Found in version 24.0.91

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #23 received at 10164 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Nicolaescu <dann <at> gnu.org>
Cc: 10164 <at> debbugs.gnu.org, tim.crews <at> code-affinity.com
Subject: Re: bug#10164: 24.0.91; Instant crash enabling linum-mode
Date: Wed, 30 Nov 2011 08:54:41 -0500
> From: Dan Nicolaescu <dann <at> gnu.org>
> Cc: Tim Crews <tim.crews <at> code-affinity.com>,  10164 <at> debbugs.gnu.org
> Date: Wed, 30 Nov 2011 07:52:40 -0500
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Date: Tue, 29 Nov 2011 19:05:20 -0700
> >> From: Tim Crews <tim.crews <at> code-affinity.com>
> >> 
> >>     Start Emacs with runemacs -Q --no-init-file
> >>     C-x C-f foo.txt
> >>     M-x linum-mode
> >>     (Emacs doesn't crash yet)
> >>     Type anything.  Emacs instantly crashes.
> >
> > Arrgh!  This is GCC 4.6.x "as-is" code reordering in action.  Emacs
> > crashes here:
> >
> > 	      xassert (!row->enabled_p
> > 		       || row->mode_line_p
> > 		       || verify_row_hash (row));
> >
> > Evidently, it calls verify_row_hash before it tests row->mode_line_p.
> 
> Are you sure?

How else can I explain this display from GDB:

  (gdb) prow
  y=0 x=0 pwid=673 a+d=12+4=16 phys=12+4=16 vis=16
  used=(LMargin=0,Text=84,RMargin=0) Hash=263825844
  start=0 end=0 ENA MODEL

?  MODEL says that this row has its mode_line_p flag set.

Just to be sure, I ran the recipe again under GDB, setting a
breakpoint inside verify_row_hash thusly:

  (gdb) break verify_row_hash if row->mode_line_p != 0

and sure enough, it breaks as soon as I turn on linum-mode, with ROW
that shows the glyphs in the mode line.

> Without interprocedural analysis the compiler cannot know
> that `verify_row_hash' does not alter row->enabled_p, so it cannot
> change the evaluation order.

I don't know.  Maybe GCC does perform such an analysis.  Or maybe it
decides that the result of this comparison in verify_row_hash:

  row->hash == row_hash (row)

will not change even if row_hash does modify its argument ROW.  Or
maybe it's a bug in GCC.




This bug report was last modified 13 years and 178 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.