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: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Thu, 25 Apr 2024 09:39:45 +0200
>> 
>> Helmut Eller <eller.helmut@gmail.com> writes:
>> 
>>  The to_bytes function looks suspisious.  Here it helps to change it to:
>> >
>> >  static mps_word_t
>> >  to_bytes (mps_word_t nwords)
>> >  {
>> > -  return nwords << 3;
>> > +  return nwords * sizeof (mps_word_t);
>> >  }
>> 
>> Oops 
>
> I installed that, since it unbreaks the build: all the Lisp files are
> now compiled successfully, and the build runs to completion.

Great!

> The resulting Emacs starts up, but then crashes due to some problem
> with Lisp strings.  I show below two backtraces from two crashes, they
> are different, but in both cases the crash is because the contents of
> what is supposed to be a 'struct Lisp string" appears to be garbled.
> In both cases, the recipe is simple:
>
>   emacs -Q
>   C-x C-f src/xdisp.c RET
>   Lean on C-v to scroll through the buffer

Not too bad that it starts at all :-). I didn't do much to ensure that
works so far.

> Sometimes the crash happens only after I release C-v, wait for a few
> seconds, then lean on C-v again; not sure if this is relevant or just
> a coincidence.

Yeah there a probably a number of data structures containing
Lisp_Objects and alike in the GUI code that are currently not traced.
Twice so if they don't exist on macOS.

> Here are the two backtraces.  Note that "xbacktrace" also reports a
> bad address, which probably means some significant issue with Lisp
> strings in general(??).
>
> Could be some alignment problem?  MPS seems to use alignment of 4 on
> 32-bit platforms, but AFAIR Emacs wants alignment of 8 for Lisp
> objects?

The alignment of MPS objects is specified around line 2761 in igc.c

    MPS_ARGS_ADD (args, MPS_KEY_FMT_ALIGN, IGC_ALIGN);

IGC_ALIGN == GCALIGNMENT at present, which is 8 for me (USE_LSB_TAG).

>
> Backtrace #1:
> Backtrace #2:

No idea at the moment, but we should make sure to trace everything
reachable in a GUI frames first. Before that's done, it's basically
guaranteed to crash at soem point.