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

Previous Next

Full log

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

From: Michael Welsh Duggan <mwd <at> cert.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
 "47244 <at> debbugs.gnu.org" <47244 <at> debbugs.gnu.org>,
 "schwab <at> linux-m68k.org" <schwab <at> linux-m68k.org>
Subject: Re: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Wed, 07 Apr 2021 15:25:16 -0400

Michael Welsh Duggan <mwd <at> cert.org> writes:

> Michael Welsh Duggan <mwd <at> cert.org> writes:
>
>> martin rudalics <rudalics <at> gmx.at> writes:
>>
>>>  > Don't know where to go from here, but I have a breakpoint set on
>>>  >
>>>  >        replace_buffer_in_windows_safely_count = 0;
>>>  >
>>>  > conditioned on count != 0.
>>>
>>> Good.  IIUC this
>>>
>>>  > (gdb) p list_length(Vwindow_list)
>>>  > $2 = 2
>>>
>>> and this
>>>
>>>  > (gdb) xlist
>>>  > $13 = 0x1a
>>>  > Lisp_Int0
>>>  > $14 = 6
>>>
>>> together indicate that Vwindow_list spontaneously shrinks from 6 to 2
>>> elements (which is "impossible" as we know already).  Attaching the next
>>> patch which should catch this situation automatically.  It will still be
>>> of no help because we won't catch the one that apparently clobbers that
>>> list but hopefully more useful than the previous diff.

Using watchpoints on Vwindow_list that are turned off when in
window_list() and ignored when it is set to nil, I was at least able to
determine that whatever is modifying the list is doing so destructively,
not by setting a new value.

-- 
Michael Welsh Duggan
(mwd <at> cert.org)

Previous Next

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