GNU bug report logs - #75710
31.0.50; feature/igc: crash report on Arch Linux, 2025-01-20

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: 75710 <at> debbugs.gnu.org
Cc: Oliver Reiter <oliver.reiter <at> snapdragon.cc>
Subject: bug#75710: 31.0.50; feature/igc: crash report on Arch Linux, 2025-01-20
Date: Wed, 22 Jan 2025 12:56:31 +0000

"Oliver Reiter via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes:

> Dear all,
>
> I opened emacs and started editing an .R file when I experienced this
> crash:

Responding to this again now I've had time to look at the backtrace:

> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=40) at /home/reitero/build/sources/emacs/emacs/src/emacs.c:432
> 432	{
> (gdb) bt
> #0  terminate_due_to_signal (sig=6, backtrace_limit=40) at /home/reitero/build/sources/emacs/emacs/src/emacs.c:432
> #1  0x00005555556d3525 in emacs_abort () at /home/reitero/build/sources/emacs/emacs/src/sysdep.c:2390
> #2  0x000055555579f3a1 in fix_lisp_obj (ss=ss <at> entry=0x7fffffffbce8, pobj=pobj <at> entry=0x7fffaa0c5168) at /home/reitero/build/sources/emacs/emacs/src/igc.c:1099
> #3  0x000055555579fc1b in fix_cons (ss=ss <at> entry=0x7fffffffbce8, cons=cons <at> entry=0x7fffaa0c5158) at /home/reitero/build/sources/emacs/emacs/src/igc.c:1889
> #4  0x00005555557a1a38 in dflt_scan_obj (ss=ss <at> entry=0x7fffffffbce8, base_start=base_start <at> entry=0x7fffaa0c5158, base_limit=base_limit <at> entry=0x7fffaa0c5170, closure=closure <at> entry=0x0)
>     at /home/reitero/build/sources/emacs/emacs/src/igc.c:1996
> #5  0x00005555557a1c2f in dflt_scanx (ss=ss <at> entry=0x7fffffffbce8, base_start=<optimized out>, base_limit=0x7fffaa0c5170, closure=closure <at> entry=0x0) at /home/reitero/build/sources/emacs/emacs/src/igc.c:2088
> #6  0x00005555557a1c6b in dflt_scan (ss=0x7fffffffbce8, base_start=<optimized out>, base_limit=<optimized out>) at /home/reitero/build/sources/emacs/emacs/src/igc.c:2099

I originally thought this indicated that a cons cell must have
moved.  Upon reflection, that's not necessarily likely: we scanned a
cons whose cdr contained nonsensical data that should never have been in
a cons cell; so something overwrote what MPS thought of a cons cell, and
probably some memory before and after it, and we might have been in a
middle of a segment and the previous object scanned by pure luck (or the
corruption might have started at the header word).

> Lisp Backtrace:
> 0xbeac8998 PVEC_SUBR
> "evil-mode-for-keymap" (0xffffc4f8)
> "evil-state-auxiliary-keymaps" (0xffffc6d8)
> "evil-state-keymaps" (0xffffcbb8)
> "evil-state-keymaps" (0xffffcdd8)
> "evil-normalize-keymaps" (0xffffd018)
> "evil-normal-state" (0xffffd4f0)
> "funcall-interactively" (0xffffd4e8)
> "command-execute" (0xffffd758)

I looked at evil-mode (hopefully, what I'm about to say applies to the
precise version you're running, too): it appears to use Fformat quite a
bit: I loaded and started it, and it was called 845 times in that Emacs
session.  Many of the calls had more than 2 arguments, which is, I
believe, most likely required for the bug to be realistic.

While unsatisfying, my very preliminary conclusion is that there is a
significant chance that this is bug#75754.  My plan is to fix this bug
unconditionally (without #ifdef HAVE_MPS) on feature/igc because I
believe the bug is present, albeit much less likely, on master, and the
ultimate fix for bug#75754 is likely to be both very different and take
some time.

Objections to this?

> In GNU Emacs 31.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
>  3.24.43, cairo version 1.18.2) of 2025-01-20 built on wilap
> Repository revision: 35437854166f8d0c1deceb7aba50f27cc838b490
> Repository branch: feature/igc
> System Description: Arch Linux
>
> Configured using:
>  'configure 'CFLAGS=-g3 -ggdb -Og -fno-omit-frame-pointer'
                                ^^^

I confess I rarely build with -Og: I'm in the -O0 team, or -Os just to
see some different compiler warnings once in a while.  Thanks for
testing with this flag; it might mean you see bugs others don't.

In particular, stack marking with -O0 behaves in a more obvious fashion
than in optimized builds; while the intention of -Og is to keep
variables in the right location for debugging, I don't know how good GCC
is at doing that in practice.

Pip

Previous Next

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