Am Donnerstag, dem 25.11.2021 um 16:18 +0100 schrieb David Kastrup: > David Kastrup <d...@gnu.org> writes: > > David Kastrup <d...@gnu.org> writes: > > > > > David Kastrup <d...@gnu.org> writes: > > > > > It's relatively reproducible, I get it every 2nd-3rd time for full > > > > > 'make doc's. Looking at the core dump, it's crashing in > > > > > System::derived_mark when marking all_elements_ because the > > > > > std::vector > > > > > has garbage in its size field (it was probably freed). What I don't > > > > > understand is how that can happen since the only way of setting > > > > > all_elements_ is in System::init_elements where the originating SCM is > > > > > also protected... > > > > > > > > My guess is that std::vector is not freed but rather not initialised. > > > > That kind of thing is what the Preinit class is supposed to prevent, but > > > > System does not use it. > > > > > > > > Note also that all_elements_ is initialised to nullptr only _after_ > > > > garbage collection has already been activated: the in-class > > > > initialisation syntax makes it easier to gloss over initialisation order > > > > (which is not changed). > > > > > > > > I'll try GC-proofing System. Only time will tell whether this makes a > > > > difference and/or whether other problems remain. > > > > > > Somewhat embarrassingly, it would not appear that anything protects > > > *all_elements_ as such (only its elements are protected in > > > System::derived_mark). That would be kind of a WTF even with Guile-1.8 > > > . > > > > Well... > > > > System::init_elements has > > > > set_object (this, "all-elements", scm_arr); > > > > So *all_elements_ is protected as part of being a Spanner. As long as > > the spanner has not committed suicide (when it drops its object list). > > If it has committed suicide but not been collected yet, *all_elements_ > > may be collected before the System itself.
Ah ok, otherwise I would have argued that all_elements_ not being initialized could only happen during construction of Systems, which is not what I'm seeing in the backtrace of the crash... > > This is garbage. > > Check out <https://gitlab.com/lilypond/lilypond/-/merge_requests/1025> > if you can trigger this with some frequency. Nope, still crashes in the same place. > Also it may be worth > figuring out whether the crash occurs in connection with frenched > systems (which are explicitly removed before the end of typesetting). How do I check this? The System that I'm marking still looks fine, as far as I can tell, but the problem with GC issues is that it can also be any other Grob running havoc (even though it's suspicious that I only see it crashing in System::derived_mark...)
signature.asc
Description: This is a digitally signed message part
