GNU bug report logs - #18438
24.4.50; assertion failed in bidi.c

Previous Next

Full log

Message #196 received at 18438 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18438 <at> debbugs.gnu.org, aidalgol <at> amuri.net
Subject: Re: bug#18438: 24.4.50; assertion failed in bidi.c
Date: Sun, 19 Oct 2014 11:37:54 -0400

On 10/19/2014 10:39 AM, Eli Zaretskii wrote:
> The rest of what the comments in w32_wnd_proc say is correct, but
> again unrelated, for the same reasons.

OK, thanks for checking.

> In fact, I cannot explain to
> myself at all how _any_ code that is not thread-safe could cause such
> a phenomenon.  I can think of no other explanations for what we see
> except some code that somehow modifies the CPU flags between the
> compare instruction and the following jump instruction.  Otherwise,
> how can it be that the value is valid, but Emacs still aborts?  Any
> other ideas?

What about your earlier suggestion (from 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18438#139) to force a 64-bit 
compare instruction for 'type', with the latter in a 64-bit register:

=== modified file 'src/bidi.c'
--- src/bidi.c	2014-04-06 15:56:01 +0000
+++ src/bidi.c	2014-10-10 07:12:01 +0000
@@ -326,7 +326,14 @@ bidi_get_type (int ch, bidi_dir_t overri
 static void
 bidi_check_type (bidi_type_t type)
 {
-  eassert (UNKNOWN_BT <= type && type <= NEUTRAL_ON);
+  volatile ptrdiff_t qtype = type;
+
+  if (!(suppress_checking || (UNKNOWN_BT <= qtype && qtype <= NEUTRAL_ON)))
+    {
+      fprintf (stderr, "\r\n%s:%d: bidi type %d is not in [%d..%d]\r\n",
+	       __FILE__, __LINE__, type, UNKNOWN_BT, NEUTRAL_ON);
+      emacs_abort ();
+    }
 }

 /* Given a bidi TYPE of a character, return its category.  */


Aidan, have you tried this yet?

Ken

Previous Next

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