The garbage collector traces objects on the FinalizeMeQ and any object referenced
from the BeingFinalized variable so that these objects pending finalization, or any
objects they reference, won't be freed by GC. However, in the current implementa-
tion of this in prepareFinalization() of gc.c, we only do this if HasFinalizerQ (a
queue of all non-garbage objects that have finalize() methods) is empty. We
should trace FinalizeMeQ and BeingFinalized in all cases.

I'm reporting this as a low-priority bug as I don't yet have evidence that it can
actually happen. It was reported by Bertrand Delsart of OSF, who I've asked
whether he's seen something go wrong as a result, or if this is from staring at
the code. It is certainly the case that even running a trivial main(), there are
things on the HasFinalizerQ as a result of startup, and on shutdown I've
observed that there are 2-3 things like objects for stdout loitering around
keeping HasFinalizerQ from being null. However, in conjunction with finaliza-
tion on exit, where we zero the HasFinalizerQ, any GC caused by finalization
would not keep any garbage objects with finalizers around, so would certainly
tickle this bug.