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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 09 Oct 2014 11:20:51 +1300
> From: aidalgol@amuri.net
> Cc: <18438@debbugs.gnu.org>, <kbrown@cornell.edu>
> 
> > --- src/bidi.c	2014-04-06 15:56:01 +0000
> > +++ src/bidi.c	2014-09-30 15:21:28 +0000
> > @@ -326,7 +326,12 @@ 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);
> > +  if (!(suppress_checking || (UNKNOWN_BT <= type && type <= 
> > 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.  */
> 
> OK, it finally happened.  It printed out...
> 
> bidi.c:332: bidi type 22 is not in [0..23]

Bidi type 22 is whitespace, most likely the SPC character.

> Isn't that a logical impossibility?

Of course, it is.  It always was.  This is what this bug is all about.

> What the hell is going on?

That's what we are trying to establish.  My working hypothesis is that
some unrelated code, either in another Emacs thread or maybe (less
likely) in the OS bowels preempts this function and doesn't restore
all the registers when it passes control back to the function.  Any
other ideas are welcome.

Could you show the disassembly of this function in its new form?  I'd
like to see if the value of the bidi type being checked is loaded into
the same register as in the original version.

Also, if you have the backtrace, including from all the other threads,
please post that.

Thanks.