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

Previous Next

Full log

Message #46 received at 18438 <at> debbugs.gnu.org (full text, mbox):

From: aidalgol <at> amuri.net
To: <18438 <at> debbugs.gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#18438: 24.4.50; assertion failed in bidi.c
Date: Tue, 16 Sep 2014 14:59:32 +1200

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?

Previous Next

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