lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC] Moving to Guile 2.2 and away from GUB


From: David Kastrup
Subject: Re: [RFC] Moving to Guile 2.2 and away from GUB
Date: Thu, 25 Nov 2021 15:14:22 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Jonas Hahnfeld via Discussions on LilyPond development
<lilypond-devel@gnu.org> writes:

> Am Donnerstag, dem 25.11.2021 um 08:40 +0100 schrieb Jonas Hahnfeld via
> Discussions on LilyPond development:
>> Am Mittwoch, dem 24.11.2021 um 23:01 +0100 schrieb Han-Wen Nienhuys:
>> > On Wed, Nov 24, 2021 at 8:13 PM Jonas Hahnfeld via Discussions on
>> > LilyPond development <lilypond-devel@gnu.org> wrote:
>> > > Assuming no major problems are found, we could then move completely to
>> > > Guile 2.2 and do releases without GUB. Both steps still require a bit
>> > > of work; I'm relatively sure there is still a GC related issue causing
>> > > (very rare) crashes with Guile 2.2
>> > 
>> > can you say more about this?
>> 
>> Not really: I remember weird crashes with dumps that were not
>> immediately obvious.
>
> 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.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]