Re: Building the igc branch on MS-Windows

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Fri, 26 Apr 2024 09:18:59 +0200
>> 
>> >> ./src/emacs -Q src/xdisp.c -eval '(igc--collect)'
>> >
>> > I would start by investigating what stuff reachable from struct frame
>> > is and is not traced, which depends a bit on the platform. Also font
>> > stuff probably, terminals, scroll bar things (at least in NS I know
>> > there is something), and I don't know what else.
>> 
>> The problem was a corrupted font.  I added the code below and it now
>> survives the first GC cycle.  In general, fix_frame must scan the same
>> fields as mark_frame in alloc.c does.  Is that about right?  Since MPS
>> wants the address of the fields (instead the value), some creativity may
>> be required.  Is that also right?  Or can I stupidly copy what
>> mark_frame does?
>
> Thanks, I cannot answer all of the questions above, but I nevertheless
> installed this in your name, with one difference:

Oh, I see, that's why the path didn't apply :-).
 
> However, the crashes while scrolling through xdisp.c are still there.
> I just had 2 of them; backtraces below.  It sounds like the first one
> is due to Lisp strings, but the second one is related to markers.
>
>   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?

>   eval.c:120: Emacs fatal error: assertion failed: pdl->kind == SPECPDL_BACKTRACE
>
>   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.

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...

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?

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.