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

["Juanma Barranquero" <lekktu@gmail.com>]

On Fri, Nov 28, 2008 at 11:56, Eli Zaretskii <eliz@gnu.org> wrote:

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

In a keymap case I found, Emacs crashed while trying to display \200.
But I could be wrong (again) about what exactly triggers the crash.

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

Not exactly a heisenbug, because it does not disappear. It moves.
That's why I've said that it always fails with draw_glyphs in the
stack, but not always in fill_glyph_string.

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

I've tried that (well, I added xassert() and/or eassert) at likely
places; they didn't get triggered.

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

Yes, I agree that GDB lies. If only the bug happened with non-optimized code...

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

I'll try to do that.

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

Sorry, I fail to understand what you are trying to say. I've suspected
that alloca'd memory is related to the crash, but I don't see how.

  Juanma