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

[aidalgol@amuri.net]

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?