bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs


From: Michael Welsh Duggan
Subject: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Thu, 18 Mar 2021 12:27:13 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Michael Welsh Duggan <md5i@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@md5i.com)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]