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

Previous Next

Full log

Message #17 received at 63711 <at> debbugs.gnu.org (full text, mbox):

From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63711 <at> debbugs.gnu.org
Subject: Re: bug#63711: 30.0.50; Crash in xdisp.c when it->string is 0x0
Date: Thu, 25 May 2023 09:50:44 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
>> Cc: 63711 <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.