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

Previous Next

Package: emacs;

Reported by: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>

Date: Thu, 25 May 2023 06:28:01 UTC

Severity: normal

Found in version 30.0.50

Done: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>

Bug is archived. No further changes may be made.

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Thomas Fitzsimmons <fitzsim <at> fitzsim.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 18:11:39 +0300
> From: Thomas Fitzsimmons <fitzsim <at> fitzsim.org>
> Cc: 63711 <at> 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?




This bug report was last modified 1 year and 347 days ago.

Previous Next


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