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