Re: --with-native-compilation build failure on 32-bit systems

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]

On Tue, Aug 9, 2022, 5:22 AM Andrea Corallo <akrl@sdf.org> wrote:

> Andrea Corallo <akrl@sdf.org> writes:
>
> [...]
>
> > Just had some time to look into this further:
> >
> > Of all the CUs we are dumping two are not fixed-up in loadup.el before
> > dump because not referenced by any function.
> >
> > In particular looking at 'ediff-hook' it does contain only variable
> > definitions so this is correct.
> >
> > We do run a GC before dumping so we should unload these unreferenced CUs
> > before dump.  And as expected I don't see ediff-hook CU being marked but
> > we do not free it during sweep.
> >
> > It looks to me like a GC bug so far.  Unfortunatly I've very constrained
> > time to dedicate on this this week.
>
> Thinking about this... Maybe relying on the GC for this is not a very
> good idea in the first place.  If we are conservative on the stack my
> might always mark a CU accidentally and fall into the same issue.
>
> I think we should maintain a list of all loaded CUs so we can fix them
> up reliably.  If this is agreed not to be a bad idea I'll prepare a
> patch.


Just a heads up - when I was validating what was failing while dumping, I
tried printing the comp units before and after they were fixed up.  When
the comp unit has a cons cell in the name field, princ segfaults (at least
in 28.1).
I didn't report this as a bug because it would be very unusual for a user
to have access to comp units in this state.

Lynn






>

[-- Attachment #2: Type: text/html, Size: 2351 bytes --]