GNU bug report logs - #5973
Crash in get_next_display_element

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: david.reitter <at> gmail.com, 5973 <at> debbugs.gnu.org
Subject: bug#5973: Crash in get_next_display_element
Date: Tue, 20 Apr 2010 11:23:04 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 20 Apr 2010 00:46:32 +0200
> Cc: David Reitter <david.reitter <at> gmail.com>, 5973 <at> debbugs.gnu.org
> 
> On Mon, Apr 19, 2010 at 20:26, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> > If not, then I'm afraid we will need to wait for another instance of
> > this crash.
> 
> I get a similar crash on Windows (trace attached).

Why do you think it is similar?  It crashes in a different place, and
if in David's case there was a hypothesis that FACE_FROM_ID returned a
null pointer, in your case I see that all face arguments are non-NULL.

What am I missing?

Btw, David's crash was in Emacs 23.1.95, so I'm pretty sure the bidi
merge has nothing to do with it.  Yours is with the trunk version,
right?

> I can reproduce it reliably, but it depends on something in my .emacs,
> so I cannot give a recipe right now.

Please do try to give a reproducible recipe.

Btw, what were you doing when it crashed?  The backtrace seems to tell
that Emacs was displaying a message in the echo area (during an Edebug
session?), and that there were characters in the message area that used
compositions, is that right?  If so, what was the text of the message?

If the crash happens even with normal ASCII characters in the echo
area, I'd prefer to see a backtrace of that variant.

Thanks.

Previous Next

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