GNU bug report logs - #47244
28.0.50; SIGSEGV in long-runnning Emacs

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Welsh Duggan <md5i <at> md5i.com>
Cc: 47244 <at> debbugs.gnu.org
Subject: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Thu, 18 Mar 2021 18:02:16 +0200

> From: Michael Welsh Duggan <md5i <at> md5i.com>
> Date: Thu, 18 Mar 2021 11:42:19 -0400
> 
> I have managed to catch a SEGFAULT in a long-running Emacs in the
> debugger.  I've been unable to recreate this SEGFAULT on demand, but it
> seems to be happening when I am attempting to "reset" gnus after
> switching my work VPN on/off.  I will keep the gdb session up an running
> in case there is some more that can be done with this.
> 
> 
> In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo version 1.16.0)
>  of 2021-03-07 built on miko
> Repository revision: c63d2ef59c511c1c48c69a202907b7edfcbb19b3
> Repository branch: md5i

This is a build from several days ago, and on some branch that is
probably a local branch.  Do the line numbers still correspond to
what's on the current master?

> #0  0x00005555555e1a61 in redisplay_internal ()
>     at ../../master/src/xdisp.c:15789

The line number here corresponds to this in the current sources:

      if (CHARPOS (tlbufpos) > BEGV
	  && FETCH_BYTE (BYTEPOS (tlbufpos) - 1) != '\n'  <<<<<<<<<<<<<<<<<
	  && (CHARPOS (tlbufpos) == ZV
	      || FETCH_BYTE (BYTEPOS (tlbufpos)) == '\n'))

Is that so in your sources as well?  If so, I'm not sure I understand
how this could segfault, given that tlbufpos is 127.  What is the
value of ZV?  And what does the following produce:

  (gdb) p current_buffer->text->beg

Previous Next

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