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> cert.org>
To: Eli Zaretskii <eliz <at> gnu.org>
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: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Thu, 08 Apr 2021 12:05:57 -0400

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

>> From: Michael Welsh Duggan <mwd <at> md5i.com>
>> Date: Thu, 08 Apr 2021 11:21:10 -0400
>> Cc: Michael Welsh Duggan <mwd <at> md5i.com>,
>>  "schwab <at> linux-m68k.org" <schwab <at> linux-m68k.org>,
>>  "47244 <at> debbugs.gnu.org" <47244 <at> debbugs.gnu.org>
>> 
>> Okay, close, but not quite.  What seems to be happening is this:
>> list_windows() is called while Vwindow_list is nil, and the if branch is
>> taken.  Something causes list_windows() to exit without reaching the end
>> of the if block.  This leaves Vwindow_list partially created.  The next
>> time list_windows() is called it returns the partially created list.
>> 
>> To determine this I put a breakpoint at the beginning of the if block
>> that sets a gdb convenience variable called $in_list_windows to one and
>> continues.  I put a breakpoint at the end of that block that sets it to
>> zero and continues.  I put a third condition breakpoint at the entrance
>> to list_windows() that only triggers if $in_list_windows is one.  This
>> triggered with the included backtrace.
>
> I guess you mean window_list instead of list_windows?

Yes, sorry.

>> Once again, the state triggered when, due to the VPN state changing, a
>> background gnus demon hung trying to fetch mail.  The trigger was me
>> hitting C-g twice rapidly in succession to regain interactivity.
>> 
>> Can anyone recommend a means to check if this my theory is true?  Does
>> list_windows() need to be protected against quit?
>
> Set a breakpoint in 'quit' and disable it.  Set another breakpoint at
> entry to 'window_list' that enables the breakpoint in 'quit', then
> another breakpoint at exit which disables the breakpoint in 'quit'.
> Then wait for the breakpoint in 'quit' to break during your recipe.
>
> Perhaps also do the same with a breakpoint in Fthrow.

Good idea!  I'm going to try that.

>
>> #26 0x000055555583108e in print_error_message
>> (data=XIL(0x55555732d343), stream=XIL(0x30), context=0x7ffff2c64148
>> "", caller=XIL(0)) at ../../master/src/print.c:944
>>         error_conditions = XIL(0x7ffff2c2da13)
>>         errname = XIL(0xb820)
>>         errmsg = make_fixnum(23456248526235)
>>         file_error = XIL(0x7fffffffd4c0)
>>         tail = XIL(0x30)
>
> What error message does this attempt to print?

(gdb) p errname
$8 = XIL(0xb820)
(gdb) xtype
Lisp_Symbol
(gdb) xpr
Lisp_Symbol
$9 = (struct Lisp_Symbol *) 0x555555e6e8a0 <lispsym+47136>
"quit"
(gdb) p errmsg
$10 = XIL(0x55555571d654)
(gdb) xpr
Lisp_String
$11 = (struct Lisp_String *) 0x55555571d650 <builtin_lisp_symbol+44>
0
(gdb) p error_conditions
$14 = XIL(0x7ffff2c2da33)
(gdb) xpr
Lisp_Cons
$15 = (struct Lisp_Cons *) 0x7ffff2c2da30
{
  u = {
    s = {
      car = XIL(0xb820),
      u = {
        cdr = XIL(0),
        chain = 0x0
      }
    },
    gcaligned = 0x20
  }
}
(gdb) xlist
$16 = 0xb820
Lisp_Symbol
$17 = (struct Lisp_Symbol *) 0x555555e6e8a0 <lispsym+47136>
"quit"
---
nil


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