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

[Eli Zaretskii <eliz@gnu.org>]

> From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> Cc: 63711@debbugs.gnu.org
> Date: Thu, 25 May 2023 09:50:44 -0400
> 
> >   (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?

No.  And pos->pos.charpos isn't supposed to be zero, since buffer
positions start from 1.  So something is very wrong there.  Please
show the results of the following commands:

  (gdb) p PT
  (gdb) frame 1
  (gdb) prow
  (gdb) pgrow
  (gdb) frame 2
  (gdb) pgrowx start_row
  (gdb) p first_reusable_row - start_row
  (gdb) p first_row_to_display - start_row
  (gdb) p first_row_to_display->y
  (gdb) p window_text_bottom_y(w)


> > 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.

But there weren't supposed to be any overlays at the beginning of the
buffer, right?  Can you describe your experiments with font-locking
JavaScript?  Which display-related features did you try?