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

[aidalgol]

On Tue, 16 Sep 2014 05:47:21 +0300, Eli Zaretskii wrote:
> > I closed the session, but I got another bidi.c assert, this time in 
> > a
> > different place.  Is this one more like bug #17817?
>
> Yes, it does.  And like that one, it makes no sense: it clearly shows
> that 'type' passed to bidi_check_type is STRONG_L, a valid value.
> Here's the relevant part of the backtrace:
>
> > #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at 
> > emacs.c:361
> > No locals.
> > #1  0x00000001005b9a67 in die (msg=0x100a5aad8 
> > <DEFAULT_REHASH_SIZE+64> "UNKNOWN_BT <= type && type <= NEUTRAL_ON", 
> > file=0x100a5aad0 <DEFAULT_REHASH_SIZE+56> "bidi.c", line=329) at 
> > alloc.c:7160
> > No locals.
> > #2  0x00000001005010fe in bidi_check_type (type=STRONG_L) at 
> > bidi.c:329
> > No locals.
> > #3  0x0000000100506230 in bidi_level_of_next_char (bidi_it=0x223d08) 
> > at bidi.c:2430
> >         type = STRONG_L
> >         level = 0
> >         prev_level = 0
> >         next_for_neutral = {
> >           bytepos = 0,
> >           charpos = -1,
> >           type = UNKNOWN_BT,
> >           type_after_w1 = UNKNOWN_BT,
> >           orig_type = UNKNOWN_BT
> >         }
> >         next_char_pos = 1
>
> The only reason I could think of for such assertion violations is 
> some
> asynchronously run code that doesn't properly restore registers.
> Which is pretty far-fetched, but what else can explain this?

I still have this session open, by the way.  Do you want anything more 
out of it?