bug#33345: 27.0.50; Abort in bidi_cache_iterator_state

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 12 Nov 2018 19:50:23 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 33345@debbugs.gnu.org
> 
> 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.bytepos--;
	  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.

Thanks.