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

Previous Next

Full log

View this message in rfc822 format

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

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

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

They do match.  It is a branch, but the changed things in the branch are
extremely unlikely to have caused this problem.  (One is a patch to gnus
summary-producing that changes how thread sorting is ordered, the other
is a patch to .gdbinit that handles running gdb on emacs when running
with the --daemon option.)  I changed the Repository revision field to
match the version of Emacs I was using.  It's several days old because
it took several days before I was able to re-trigger this problem.

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

(gdb) p ZV
$6 = 127
(gdb) p current_buffer->text->beg
$7 = (unsigned char *) 0x0

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

Previous Next

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