bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#18438: 24.4.50; assertion failed in bidi.c


From: Ken Brown
Subject: bug#18438: 24.4.50; assertion failed in bidi.c
Date: Sun, 19 Oct 2014 11:37:54 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]