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

[Eli Zaretskii]

> Date: Tue, 30 Sep 2014 12:09:32 -0400
> From: Ken Brown <kbrown@cornell.edu>
> CC: 18438@debbugs.gnu.org
> 
> On 9/30/2014 11:24 AM, Eli Zaretskii wrote:
> > OK, so far so good.  How about the one below (which tries to reveal
> > the face of the beast)?
> >
> > === modified file 'src/bidi.c'
> > --- 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.  */
> 
> Wouldn't it make sense for him to first see if your recent fix of the 
> "Current trunk aborts with MinGW" problem also fixes the present bug? 

Could be, yes.  I actually thought about this possibility, but didn't
mention it because I couldn't come up with a scenario where that bug
could have triggered such strange problems, and only in bidi.c.  But
it does no harm to try applying that patch first, and only apply this
one if that doesn't help.

> We speculated previously that these strange assertion violations might 
> be a result of the w32_msg stuff not being thread safe.

Yes, but you need memory allocation in the picture to have that, and I
see no such allocation in the sequence of calls we saw in the
backtraces.

Still, "the proof of the pudding is in eating"...

Thanks.