GNU bug report logs - #75599
31.0.50; scratch/igc: crash on commit 92ccf1c after opening file and REPL

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: 75599 <at> debbugs.gnu.org, eliz <at> gnu.org
Cc: oliver.reiter <at> snapdragon.cc
Subject: bug#75599: 31.0.50; scratch/igc: crash on commit 92ccf1c after opening file and REPL
Date: Sat, 18 Jan 2025 02:11:51 +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 hit this crash today after opening a .jl (julia-mode) file and
> starting a REPL. I am using a Doom Emacs configuration.

Thanks for the report!  I'm not familiar with julia-mode or Doom Emacs,
but I'll have a look to see whether there's any obviously unusual stuff
they do.

> I built emacs with commit 92ccf1c7539fe00ec04be6bc1603b649db560c37
> yesterday. I have the gdb session still open, if any further infos are
> needed.

In cases like this one, it's always a good idea to generate a core dump
from within GDB.  That way, there's still a chance to debug things if
the GDB session is closed or you do something irreversible from GDB.

The relevant GDB command is "gcore".  Please also ensure to preserve a
copy of the "emacs" executable that generated the core file, as the core
file will be much less useful without that.

> Also, in the gdb session I see quite a lot of messages like this:
>
> warning: Corrupted shared library list: 0x5555571e2550 != 0x555557202ed0
>
> Should this too be investigated?

That sounds like a GDB bug.  While the GDB bug tracker is currently a
bit of a graveyard, it's still a good idea to report such bugs.

> Here is the backtrace:
>
> Thread 1 "emacs" received signal SIGSEGV, Segmentation fault.
>
> buffer.c:579: Emacs fatal error: assertion failed: size > 0
>
> Thread 1 "emacs" hit Breakpoint 1, terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at /home/reitero/build/sources/emacs/emacs/src/emacs.c:432
> 432	{
> (gdb) bt
> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at /home/reitero/build/sources/emacs/emacs/src/emacs.c:432
> #1  0x000055555579e5df in set_state (state=<optimized out>) at /home/reitero/build/sources/emacs/emacs/src/igc.c:975
> #2  0x00005555557934a2 in igc_assert_fail (file=<optimized out>, line=<optimized out>, msg=<optimized out>) at /home/reitero/build/sources/emacs/emacs/src/igc.c:276
> #3  0x00005555558333ec in BufferFill ()
> #4  0x0000555555868e20 in amcSegFix ()
> #5  0x0000555555802d6d in _mps_fix2 ()
> #6  0x000055555579bfda in fix_raw (ss=ss <at> entry=0x7fffffff5958, p=p <at> entry=0x7fffffff57d0) at /home/reitero/build/sources/emacs/emacs/src/igc.c:1145
> #7  0x000055555579c0a3 in fix_string (ss=ss <at> entry=0x7fffffff5958, s=s <at> entry=0x7fffb88e48e8) at /home/reitero/build/sources/emacs/emacs/src/igc.c:1738
> #8  0x00005555557a05e0 in dflt_scan_obj (ss=ss <at> entry=0x7fffffff5958, base_start=base_start <at> entry=0x7fffb88e48e8, base_limit=base_limit <at> entry=0x7fffb88e6000, closure=closure <at> entry=0x0)
>     at /home/reitero/build/sources/emacs/emacs/src/igc.c:2005
> #9  0x00005555557a0793 in dflt_scanx (ss=ss <at> entry=0x7fffffff5958, base_start=<optimized out>, base_limit=0x7fffb88e6000, closure=closure <at> entry=0x0)
>     at /home/reitero/build/sources/emacs/emacs/src/igc.c:2072
> #10 0x00005555557a07cf in dflt_scan (ss=0x7fffffff5958, base_start=<optimized out>, base_limit=<optimized out>) at /home/reitero/build/sources/emacs/emacs/src/igc.c:2083

This is a common symptom of resurrecting an untraced object whose memory
has been freed.  In this case, it's a string, but we don't know which
other object referred to it, and how it managed to slip the reference
past MPS.

What might help us is to look at that string, but it is the string data
which was overwritten, which is unfortunate.

I've toyed with the idea of modifying igc.c so it's possible to get an
explicit view of the heap for debugging for a while.  Maybe it's time to
do that.

Is this bug at all reproducible?  Further crash reports might help, or I
could modify the igc.c code and we could gather more information.

If it isn't, we should try inspecting the core dump.

General GDB question (CCing Eli because he knows much more than I do
about GDB): is there some way to run "find", but have it search all the
memory ranges that are present in the relevant core dump?

Or, at least, find out which ranges are present?  I know "objdump -h"
provides that information, but it's not the most friendly of formats.

I've usually just resorted to inspecting the core dump in hexl mode for
that, but that's hardly ideal.  It would be helpful in this case because
I don't have (or want) access to the core dump file produced by someone
else's Emacs session.

If there isn't, we'll have to use objdump:

After dumping core (but don't quit the GDB session yet, just generate a
core file and save it somewhere :-) ), please run this in bash:

objdump -h <PATH_TO_COREFILE>  | egrep '^[0-9]' | while read N NAME SIZE START REST; do echo "find 0x$START,0x$START + 0x$SIZE,0x7fffb88e48e8"; done

This produces a number of gdb commands, which you can paste into the
(live) GDB session.  Most of them will say "Pattern not found.", but
there's a chance some will also output an address.  For such addresses,
please run

x/32gx <ADDRESS> - 128

(note the offset -128 is important, because we need to see the object's
header)

This should allow us to find the object which referred to the string,
and maybe that helps.

Thanks!
Pip

Previous Next

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