Subject: Re: bug#31245: 27.0.50; Crash in Windows emacs

From: Eli Zaretskii <[email-masked]>
Date: Mon, 21 May 2018 22:12:20 +0300

> From: Andy Moreton <[email-masked]>
> Date: Mon, 21 May 2018 18:51:03 +0100
> 
> I am unlikely to find a recipe to reproduce this, as it only occurs
> after several hours of normal usage of emacs, and does not seem
> correlated to any set of buffers modes, input etc.

So you are saying this is some kind or Heisenbug, something like
memory corruption?  Is it possible that your system is in some kind of
trouble unrelated to Emacs?

> I can now get gdb running sometimes on this system. Let me know anything
> that you would find useful to look at in gdb if I manage to reproduce
> this again.

Emacs aborts because it was asked to pop an empty stack, that's what
happens here.  The question is how did it happen that we are trying to
pop an empty stack.  And the answer is in stuff that happened before
this, which led to this situation.

The bidi iterator keeps state, and here that state somehow became
corrupted.  To understand why, we need at least partially retrace what
happened immediately prior to this abort.  That's why some kind of
recipe, or at least a description of what's in the buffer, is needed.

Do you happen to know what is in the buffer, and how are the overlay
strings arranged in the buffer?

> #2  0x0000000400101ed7 in bidi_pop_it (bidi_it=0xbf9398) at C:/emacs/git/emacs/master/src/bidi.c:947
> No locals.
> #3  0x000000040003cc28 in pop_it (it=0xbf89a0) at C:/emacs/git/emacs/master/src/xdisp.c:6265
>         p = 0xbf8c28
>         from_display_prop = 0x0
>         prev_pos = 0x1e7b7
> #4  0x000000040003a534 in next_overlay_string (it=0xbf89a0) at C:/emacs/git/emacs/master/src/xdisp.c:5662
> No locals.
> #5  0x00000004000411c4 in set_iterator_to_next (it=0xbf89a0, reseat_p=0x1) at C:/emacs/git/emacs/master/src/xdisp.c:7779

This part tells us that we were displaying an overlay string, reached
the end of the overlay string, and popped the iterator stack.  That
causes us to pop the bidi iterator stack as well, but we have found
that the latter is empty, which simply cannot happen when we display
an overlay string, because when we start displaying the overlay
string, we push some data onto the bidi stack.

So I guess this means bidi_pop_it was called twice in a row without an
intervening bidi_push_it.  If you can find out how did that happen, we
may be on the way to solution.

Thanks.