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

Previous Next

Package: emacs;

Reported by: aidalgol <at> amuri.net

Date: Tue, 9 Sep 2014 21:52:01 UTC

Severity: normal

Tags: moreinfo

Merged with 17817

Found in versions 24.3.91, 24.4.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: 18438 <at> debbugs.gnu.org, aidalgol <at> amuri.net
Subject: bug#18438: 24.4.50; assertion failed in bidi.c
Date: Tue, 30 Sep 2014 19:27:37 +0300
> Date: Tue, 30 Sep 2014 12:09:32 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> CC: 18438 <at> 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.




This bug report was last modified 9 years and 154 days ago.

Previous Next


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