bug#10035: Crash in check_x_frame in w32fns.c

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 13 Nov 2011 13:55:30 -0700
> From: Christoph Scholtes <cschol2112@googlemail.com>
> CC: 10035@debbugs.gnu.org
> 
> On 11/13/2011 1:21 PM, Eli Zaretskii wrote:
> 
> > Sorry, I meant to type this in frame #2, where a and be are arguments
> > of the function row_equal_p:
> >
> >> #2  0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1)
> >>       at dispnew.c:398
> 
> (gdb) p a->enabled_p
> $2 = 1
> (gdb) p b->enabled_p
> $3 = 1

Good.  Now let's see what are these two glyph rows:

 (gdb) prowx a
 (gdb) prowx b
 (gdb) pgrowx a
 (gdb) pgrowx b

The last two commands will display all the display elements
(characters, references to images and display strings, etc.) in each
glyph row.  Assuming it is not a total garbage, please try to describe
what happened on the screen around these glyph rows (== screen lines).

A bit of a background: scrolling_window, the function that called
row_equal_p, is comparing the previous and the new contents of a
window, trying to figure out which screen lines need to be redrawn and
which can be reused from the previous redisplay cycle.  row_equal_p is
the comparison function.  So one of the glyph rows should be from the
window before some update, the other glyph row is from the new
contents of the window.  They could be identical or they could be
different.

> >    #2  0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1)
> >         at dispnew.c:398
> >    #3  0x010f490f in scrolling_window (w=0x10d96000, header_line_p=0)
> >         at dispnew.c:398
> >    #4  0x010f30fe in update_window (w=0x10d96000, force_p=1) at dispnew.c:398
> >    #5  0x010f27fe in update_window_tree (w=0x10d96000, force_p=1)
> >         at dispnew.c:398
> >    #6  0x010f27d7 in update_window_tree (w=0x10d72200, force_p=1)
> >         at dispnew.c:398
> >    #7  0x010f254d in update_frame (f=0x3a24e00, force_p=1, inhibit_hairy_id_p=0)
> >         at dispnew.c:398
> >
> > We are obviously very smart if we succeeded to squeeze all these
> > functions into a single source line ;-)
> 
> Interesting. I didn't notice that.
> 
> > What version of GCC is that?
> 
> tdm-gcc 4.6.1

If this is an unoptimized build, this shouldn't happen, and perhaps
it's a compiler bug.  Or maybe GCC 4.6 does some optimizations even
with -O0.