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

Previous Next

Full log

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

From: aidalgol <at> amuri.net
To: <18438 <at> debbugs.gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#18438: 24.4.50; assertion failed in bidi.c
Date: Mon, 20 Oct 2014 08:49:47 +1300

On Sun, 19 Oct 2014 11:37:54 -0400, Ken Brown wrote:
> 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?

Oops!  No, I somehow missed this patch when I first read that post.  I 
think I absent-mindedly mistook it for the same patch as the one in 
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=18438#103>.  Applying now 
and doing a clean build.  Note that this means that my last backtrace 
was with the patch in message #103, *NOT* the one in #139 that forces a 
64-bit comparison.

Previous Next

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