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

[Eli Zaretskii]

> Date: Tue, 16 Sep 2014 13:04:12 +1200
> From: aidalgol@amuri.net
> Cc: Eli Zaretskii <eliz@gnu.org>
> 
> 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?