Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 24 Apr 2024 18:48:25 +0200
>> 
>> Could you please walk up the stack frames? Is something from us there?
>
> Quite a lot, actually.  Here's the entire backtrace, for your fun:

>   #10 0x007e435b in _mps_fix2 (mps_ss=0x656f818, mps_ref_io=0x656f700)
>       at trace.c:1433
>   #11 0x006ef08a in fix_lisp_obj (ss=0x656f818, pobj=0xcd1aec <globals+396>)
>       at igc.c:428
>   #12 0x006ef27b in scan_staticvec (ss=0x656f818, start=0xccf940 <staticvec>,
>       end=0xcd1940 <consing_until_gc>, closure=0x0) at igc.c:534

Ah, finally familiar territory ;-). #

Seriously, this looks like (more down the stack) we're in the process of
allocating a cons, MPS finds it must collect, and things get rolling. In
#12, we're processing staticvec, fix_lisp_obj is called for processing
one of the entries, MPS_FIX12 is called and finds something is wrong.

If I had to make an uneducated guess, it doesn't like the reference we
pass to it.

The thing is that MPS_FIX1 should return true if a reference is
interesting for MPS_FIX2'ing it. My understanding of the docs would be
"if and only if" there reference is interesting for MPS_FIX2, but I
wouldn't swear that the docs says "iff". I think they don't say that
explicitly.

Anyway. In fact, I had cases before where I couldn't pass any arbitrary
reference to MPS_FIX1, because it would "falsely" return true, and
MPS_FIX2 would then complain.

That's the background/history of is_mps in igc.c.

Or IOW, I would propose to see what's special about the pointer in #12.