GNU bug report logs - #1448
23.0.60; update to cvs emacs crash report

Previous Next

Packages: w32, emacs;

Reported by: Feng li <fengli <at> blackmagic-design.com>

Date: Fri, 28 Nov 2008 05:25:04 UTC

Severity: grave

Merged with 872, 1179, 1446, 1447

Found in version 23.0.60

Done: Jason Rumney <jasonr <at> f2s.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Juanma Barranquero" <lekktu <at> gmail.com>
To: "Eli Zaretskii" <eliz <at> gnu.org>
Cc: 1448 <at> debbugs.gnu.org, "Feng li" <fengli <at> blackmagic-design.com>
Subject: bug#1448: 23.0.60; update to cvs emacs crash report
Date: Fri, 28 Nov 2008 12:23:33 +0100
On Fri, Nov 28, 2008 at 11:56, Eli Zaretskii <eliz <at> 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




This bug report was last modified 16 years and 161 days ago.

Previous Next


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