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

[Andrea Corallo]

Andrea Corallo <akrl@sdf.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>>> Joseph Mingrone <jrm@ftfl.ca> writes:
>>>
>>>> Could 261d6af have broken --with-native-compilation builds on 32-bit
>>>> systems?  This is what I see building in a clean FreeBSD/i386 13.0
>>>> jail using 261d6af:
>>>> http://pkg.ftfl.ca/data/13i386-default/2022-08-04_22h38m28s/logs/errors/emacs-devel-29.0.50.20220804,2.log
>>>
>>> I guess these are the error messages?
>>>
>>> emacs: Trying to load incoherent dumped eln file
>>> /wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-261d6af/native-lisp/29.0.50-7cc1a43d/preloaded/ediff-hook-0b92f1a2-f843c8a0.eln
>>>
>>> I don't know what that means; Andrea added to the CCs.
>>
>> It's very surprising to see 261d6af causing this side effect, at least I
>> don't see why should effect the 32bit build only.
>>
>> I'm trying to reproduce it on my 32bit env.
>
> I confirm the build it's broken on my 32bit env as well, (but not on the
> 64 one).
>
> Loading the second dump, while we are relocating the ediff-hook
> compilation unit, we realize (@ pdumper.c:5304) that its file field is
> not a cons as expected but just a string.
>
> Now the question is why this is not fixed-up in loadup.el:477 as for the
> other compilation units?

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.

BR

  Andrea