GNU bug report logs - #75870
30.0.93; feature/igc: Breakpoint 1, terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at ./src/emacs.c:432

Previous Next

Full log

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

From: Gregor Zattler <telegraph <at> gmx.net>
To: Pip Cet <pipcet <at> protonmail.com>, bug-gnu-emacs <at> gnu.org,
 75870 <at> debbugs.gnu.org
Subject: Re: bug#75870: 30.0.93; feature/igc: Breakpoint 1,
 terminate_due_to_signal (sig=sig <at> entry=6,
 backtrace_limit=backtrace_limit <at> entry=40) at ./src/emacs.c:432
Date: Tue, 28 Jan 2025 23:55:22 +0100

Hi Pip,
* Pip Cet <pipcet <at> protonmail.com> [2025-01-28; 18:26 GMT]:
> "Gregor Zattler via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes:
>> when I switched to the Emacs frame it
>> stayed blank and in GDB I saw
>>
>> Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at ./src/emacs.c:432
>
> That means we aborted, which may be hard or easy to track down.  In this
> case, it's the latter.
>
>> it wasn't me who signalled to Emacs, at
>> least not deliberately.  Therefore i
>> wouldn't know how to reproduce.
>
> abort() is handled on GNU/Linux by making a process send a signal to
> itself, and then it will terminate upon receiving it.
>
>> I started another instance of this very
>> Emacs build in order to get the version
>> and configuring info, see next.  At the
>> very end of this email find the GDB
>> output from 'bt' and 'xbacktrace' (the
>> latter empty).
>
> So these are two backtraces?

I did "bt" and it resulted in the output
and then "xbacktrace" which did not add
additional lines (no output).


>> If you have questions involving GDB
>> please give specific instructions how to
>> get the needed info.
>
>> HTH, Gregor
>
> It definitely does!
>
>> Breakpoint 1, terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at ./src/emacs.c:432
>> 432	{
>> #0  terminate_due_to_signal (sig=sig <at> entry=6, backtrace_limit=backtrace_limit <at> entry=40) at ./src/emacs.c:432
>> #1  0x00005555555b39a2 in emacs_abort () at ./src/sysdep.c:2390
>> #2  0x00005555555cc9ff in igc_check_freeable (start=start <at> entry=0x555556646030) at ./src/igc.c:3068
>
> I wrote igc_check_freeable to catch cases in which an igc_xzalloc was
> paired with an xfree rather than an igc_xfree.  If undetected, such
> unbalanced calls would leak roots, which can be a major slowdown.
>
>> #3  0x00005555557ef088 in xfree (block=0x555556646030) at ./src/alloc.c:842
>> #4  xfree (block=0x555556646030) at ./src/alloc.c:835
>> #5  0x000055555571e72c in xi_disable_devices (dpyinfo=dpyinfo <at> entry=0x555556633190, to_disable=to_disable <at> entry=0x7fffffffb340, n_disabled=n_disabled <at> entry=1) at ./src/xterm.c:13970
>
> That line is:
>
>       xfree (dpyinfo->devices);
>
> You know where this is going.  Here's where we allocated it:
>
> #ifdef HAVE_MPS
>   // FIXME/igc: use exact references
>   dpyinfo->devices = igc_xzalloc_ambig (sizeof *dpyinfo->devices * ndevices);
> #else
>   dpyinfo->devices = xzalloc (sizeof *dpyinfo->devices * ndevices);
> #endif
>
> So the we shouldn't call xfree, but:
>
> #ifdef HAVE_MPS
>   igc_xfree (dpyinfo->devices);
> #else
>   xfree (dpyinfo->devices);
> #endif
>
>> #6  0x0000555555730ede in xi_disable_devices (n_disabled=1, to_disable=0x7fffffffb340, dpyinfo=0x555556633190) at ./src/xterm.c:13885
>
> I'm not entirely sure what precisely a device is in terms of XI.  Did
> you add or remove a mouse/keyboard/touchscreen, or suspend and resume
> your computer?  Or maybe connect or disconnect from a docking station?
> Many USB devices are also "input" devices, so it might have been one of
> those, like a hardware security token (which emulates a keyboard) or a
> sound device (which has buttons which might be handled by XI).

That's quite likely, I played at the
time with "udisksctl power-off  -b
/dev/sdb" to remove an usb-storage
device which is in a dock.  It might be
that I did that while the Emacs session
in question was running, not sure
thought.

It just tried, if issuing this command
stops the MPS-enabled Emacs but it
didn't, so could not reproduce.


> Here's the patch:
>
> From aad2659d864d7ab2f81ab1983a5d85e966d14708 Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet <at> protonmail.com>
> Subject: [PATCH] [MPS] Fix crashes on XI devices being disabled (bug#75870)
>
> * src/xterm.c (x_free_xi_devices):
> (xi_disable_devices) [HAVE_MPS]: Use 'igc_xfree', not 'xfree'.
> ---
>  src/xterm.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/src/xterm.c b/src/xterm.c
> index ada7fbc2e41..049e283cdbc 100644
> --- a/src/xterm.c
> +++ b/src/xterm.c
> @@ -5414,7 +5414,11 @@ x_free_xi_devices (struct x_display_info *dpyinfo)
>  #endif /* HAVE_XINPUT2_2 */
>  	}
>
> +#ifdef HAVE_MPS
> +      igc_xfree (dpyinfo->devices);
> +#else
>        xfree (dpyinfo->devices);
> +#endif
>        dpyinfo->devices = NULL;
>        dpyinfo->num_devices = 0;
>      }
> @@ -13967,7 +13971,11 @@ xi_disable_devices (struct x_display_info *dpyinfo,
>      }
>
>    /* Free the old devices array and replace it with ndevices.  */
> +#ifdef HAVE_MPS
> +  igc_xfree (dpyinfo->devices);
> +#else
>    xfree (dpyinfo->devices);
> +#endif
>
>    dpyinfo->devices = devices;
>    dpyinfo->num_devices = ndevices;


will try and the one in the your thanks,
next email.


Since I'm not able to reproduce I'll
simply use it and wait.

Ciao; Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

Previous Next

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