bug#1448: 23.0.60; update to cvs emacs crash report

[Eli Zaretskii]

> Date: Fri, 28 Nov 2008 10:25:09 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: 1448@emacsbugs.donarmstrong.com
> 
> What you're seeing is bug#872 (also #1179).
> 
> I originally thought it depended on
> `display-unibyte-via-language-environment', but it is not so; I've
> seen it (and suffered it) through several different incarnations.
> 
> What they all have in common:
> 
>  - Using a "recent" MinGW GCC (4.2.1, 4.3.0-alpha, etc.)
>  - Compiling with optimization

Now I understand why I cannot reproduce this: I never bothered to
upgrade to GCC 4.x.

>  - Trying to display unibyte (or, perhaps, some composed characters,
> I'm not sure)

How does "C-h b" get to display unibyte or composed characters?

> I've been trying to debug it, without success (it doesn't help that I
> know very little about the glyph handling code). I'm not even sure
> whether it is a compiler bug, or a bug in Emacs (it happens in code
> that was undergoing changes quite recently).

Is it a Heisenbug? i.e., does it disappear if you add printf's around
the code that crashes or in its callers?

If the bug stays put when code around it is modified, you could try
debugging it by adding "if (something) abort ();" lines testing
various conditions that are suspect of causing the crash.

Some observations based on the traceback posted by Feng Li:

> Program received signal SIGSEGV, Segmentation fault.
> 0x0101fdd5 in fill_glyph_string (s=0x820000, face_id=27, start=<value 
> optimized out>, end=<value optimized out>, overlaps=<value optimized out>) at 
> xdisp.c:19740

Line 19740 in xdisp.c is this:

  s->ybase += voffset;

And "bt full" says this about `s':

>       s = (struct glyph_string *) 0x0

However, `s' is dereferenced many times in `fill_glyph_string' before
it gets to line 19740, so I think GDB lies about the place where it
crashed (because GCC optimizes code to the degree that any relation
between the code and the source lines is lost).

Therefore, the first thing to do is disassembly the vicinity of the
crash locus (0x0101fdd5) and see which code, exactly, crashes, and
why.  Disassembly should establish (1) the source line that crashes,
and (2) which C-level variable causes the crash.

Note that `s' is allocated via `alloca' in BUILD_CHAR_GLYPH_STRINGS,
which is called by BUILD_GLYPH_STRINGS, which in turn is called by
`draw_glyphs' at line 20332 in frame #1:

> #1  0x01040a0c in draw_glyphs (w=0x3439800, x=72, row=0x3345260, 
> area=TEXT_AREA, start=0, end=30, hl=DRAW_NORMAL_TEXT, overlaps=0) at 
> xdisp.c:20332

The original source line 20332 in xdisp.c looks like this:

  BUILD_GLYPH_STRINGS (i, end, head, tail, hl, x, last_x);