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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Welsh Duggan <mwd <at> md5i.com>
Cc: 47244 <at> debbugs.gnu.org, schwab <at> linux-m68k.org, mwd <at> cert.org
Subject: Re: bug#47244: 28.0.50; SIGSEGV in long-runnning Emacs
Date: Thu, 08 Apr 2021 18:58:15 +0300

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

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

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

Previous Next

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