[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#33345: 27.0.50; Abort in bidi_cache_iterator_state

From: Eli Zaretskii
Subject: bug#33345: 27.0.50; Abort in bidi_cache_iterator_state
Date: Tue, 13 Nov 2018 20:05:34 +0200

> Date: Mon, 12 Nov 2018 19:50:23 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> And one more question: does the system/configuration where you see the
> crash differ from the others in the font used to display the offending
> text?  The shaping of Arabic could depend on the font being used, due
> to differences in OTF features supported by the fonts.

I've thought about this some more, and I really don't understand how
this could happen.  The offending call to bidi_cache_iterator_state is
from here:

  /* Prepare the sentinel iterator state, and cache it.  When we bump
     into it, scanning backwards, we'll know that the last non-base
     level is exhausted.  */
  if (bidi_cache_idx == bidi_cache_start)
      bidi_copy_it (&sentinel, bidi_it);
      if (bidi_it->first_elt)
          sentinel.charpos--;   /* cached charpos needs to be monotonic */
          sentinel.ch = '\n';   /* doesn't matter, but why not? */
          sentinel.ch_len = 1;
          sentinel.nchars = 1;
      bidi_cache_iterator_state (&sentinel, 1, 0);  <<<<<<<<<<<<<<<<

But this means that the cache is empty, and we can never scan back
(scan_dir = -1) when the cache is empty.  So something very strange
happened there.

Instead of me asking you gobs of questions, perhaps you could give me
an ssh login on that system, and arrange for a GDB session which
already hit the call to emacs_abort to be in a state where I can
switch to it after logging in (with 'screen' or 'tmux', I think).
Then I could look around and see if I find out some clues.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]