bug#35429: 27.0.50; Arbitrary xdisp.c related crashes when working with overlay-using packages

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Thu, 25 Apr 2019 11:36:27 -0400
> 
> In the past one-two weeks

Any chance for a more accurate time frame?  Or maybe even bisection?

> I have been noticing arbitrary crashes when working in Org mode, with other
> packages like org-tree-slide and artist-mode. My guess is that this has to do 
> with packages dealing with
> overlays.
> 
> I do not have a reproducible recipe, but this time, I got the full backtrace 
> (attached as gdb.txt).

Thanks.  Unfortunately, the backtrace makes no sense to me.  The
buffer was pure ASCII, right?  At least for the first 2K characters it
seems the answer is yes, because:

> #4  0x0000000000584793 in line_number_display_width (w=w@entry=0x89da880, 
> width=width@entry=0x7fffffff43dc, 
> pixel_width=pixel_width@entry=0x7fffffff43e0) at indent.c:1981
>         startpos = {
>           charpos = 2874, 
>           bytepos = 2874
>         }

As you see, the character and the byte positions coincide, which is a
sign of a plain ASCII buffer text.

So it makes little sense that the assertion is violated, because it is
called to validate the same character position of 2874:

> #1  0x00000000005a1232 in die (msg=msg@entry=0x680450 "charpos == 
> BYTE_TO_CHAR (bytepos)", file=file@entry=0x67dc6a "xdisp.c", 
> line=line@entry=3047) at alloc.c:7221
> No locals.
> #2  0x0000000000456b44 in init_iterator (it=it@entry=0x7fffffff3040, 
> w=w@entry=0x89da880, charpos=2874, bytepos=<optimized out>, row=<optimized 
> out>, base_face_id=base_face_id@entry=DEFAULT_FACE_ID) at xdisp.c:3047

So something strange is at work here, and I cannot see what it could
be, especially with all those "optimized out" variables.

I would suggest to try an unoptimized build, and if the same crashes
happen there as well, perhaps the backtrace will tell something more
useful.  It would help to know the value of bytepos argument to
init_iterator, and if it indeed is equal to charpos, the next thing to
look at is the buffer's markers.

Thanks.