Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Helmut Eller <eller.helmut@gmail.com>,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 10:11:28 +0200
> 
> >   igc.c:1584: Emacs fatal error: assertion failed: !"other"
> 
> That's the PVEC_OTHER we talked about.
> 
> Maybe it would be a good idea to take the assert !"other" out for the
> moment?

No, we should instead solve that.  Moving assertions out of the way
just sweeps real problems under the carpet, which makes little sense
to me.  These problems need to be solved, or else they will pile up
for no good reason.  It isn't like we are going to release this branch
soon, so avoiding these aborts has no useful purpose, IMO.

> >   Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=22,
> >       backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:442
> >   442     {
> >   The program being debugged stopped while in a function called from GDB.
> >   Evaluation of the expression containing the function
> >   (backtrace_function) will be abandoned.
> >   When the function is done executing, GDB will silently stop.
> 
> This is from the xbacktrace calling into Emacs.

Yes, I know.

> And now it's becoming fun :-).
> 
> Our GC callbacks are called from MPS, in its thread. Fix_... are
> subroutines of dftl_scan, which is the scanning callback. When we fail,
> MPS is in some state we don't really know. And Emacs does its thing
> handling the failure, which uses MPS (it allocates, for example).
> 
> Which basically means, after a failing assertion in a callback, we are
> basically hosed. Memory barriers may exist, locks may not have been
> released, and heaven knows...

xbacktrace (and some of the other .gdbinit commands, like "pp", which
calls into Emacs) are known not to work reliably when Emacs crashed,
so the fact that this happens here is not a surprise to me.

> Sometimes it helps to put MPS into a post-mortem state, as MPS calls it.
> There is igc_postmorten which can be called from the debugger. That at
> least lifts the memory barriers.
> 
> Does that make sense?

Yes, it does.  Maybe xbacktrace should do that automatically?  What
are the downsides of calling igc_postmorten?

> I think we should first get to a state where we don't fail asserts,
> because it's hard to tell if followup errors are "real", so to say.

Agreed.