Re: [scratch/igc] 985247b6bee crash on Linux, KDE, Wayland

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 06 Sep 2024 19:29:28 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gerd.moellmann@gmail.com, emacs-devel@gnu.org
> 
> So we can decode those to three interleaved lists reading, in part:
> 
> (nil font-lock-face (:foreground ...))
> (rear-nonsticky t <bad symbol> ...)
> (nil font-lock-face (...))
> 
> <bad symbol> is a pointer to what looks like the nursery generation, but
> one which we must have failed to trace (presumably the symbol was either
> uninterned and freed or interned and moved to an older generation) and
> which was subsequently reused for cons cells by composite.c
> 
> Going back to the original report, I notice that it was trying to print
> an "error in process filter: " message while handling what looks like a
> (long) sequence of terminal escape codes.  Were you using M-x term at
> the time?  Did you notice such error messages?
> 
> I'll have another look at the process filter/longjmp code, but I suspect
> we're going to have to wait for further crashes to get to the bottom of
> this.

What data is missing to get to the bottom of this, and how can we
change the code and/or add some .gdbinit magic to provide that data?

In general, our current facilities to investigate igc-related crashes
are clearly insufficient.  The old GC has the last_marked[] array,
which could be used to trace back any bad values which caused a
GC-related crash, and I used that on several occasions.  But there's
nothing similar in igc.c, which makes the investigation basically a
guesswork.  How can we improve this situation?  I expect this kind of
trouble to happen a lot in the near future, so having efficient tools
for debugging is crucial, IMO.