bug#63711: 30.0.50; Crash in xdisp.c when it->string is 0x0

[Thomas Fitzsimmons]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
>> Cc: 63711@debbugs.gnu.org
>> Date: Thu, 25 May 2023 09:02:26 -0400
>> 
>> >   (gdb) p it->sp
>> 
>> $11 = 0
>> 
>> >   (gdb) p it->method
>> 
>> $12 = GET_FROM_BUFFER
>
> These last two values are already a sign of trouble, AFAIU.  We are
> trying to find an overlay string where there is none.  But if that is
> the case, how come pos->overlay_string_index is non-negative? that
> should not happen.

OK, interesting.

>> The session is still open if you want me to check other values.
>
> Do you know what kind of buffer is the current buffer in this case?
> The following command will show some of the buffer text near the
> position that is examined here, to possibly help you figure out the
> buffer:
>
>   (gdb) p (*BYTE_POS_ADDR(pos->pos.bytepos))@100
>
> (Here 100 is the number of bytes to display; feel free to use more if
> 100 is insufficient.)

$14 = "\000\000;; js.el --- Major mode for editing JavaScript  -*- 
lexical-binding: t -*-\n\n;; Copyright (C) 2008-"

> Once you do understand what buffer is this, please try to describe the
> overlays at buffer position pos->pos.charpos in that buffer, if there
> are supposed to be any overlays there.

(gdb) p pos->pos.charpos
$16 = 0

So I guess the first 100 characters printed above already shows the
context at pos->pos.charpos?  Are those leading zero-bytes expected?

> That position is supposed to be the first position of a screen line,
> i.e. the position of the leftmost character on display in that line.

I was experimenting with font-locking JavaScript.  Maybe I put Emacs
into a strange state that way (though it still shouldn't be crashable).
I can't visually inspect the affected window anymore; it was an X11
window, tunneled through an SSH connection which I've since closed.

Thanks,
Thomas