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