[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:52:17 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
David Kastrup <dak@gnu.org> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> 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.
>
> 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.
This is garbage.
--
David Kastrup
Re: [RFC] Moving to Guile 2.2 and away from GUB, Han-Wen Nienhuys, 2021/11/24
- Re: [RFC] Moving to Guile 2.2 and away from GUB, Jonas Hahnfeld, 2021/11/25
- Re: [RFC] Moving to Guile 2.2 and away from GUB, Jonas Hahnfeld, 2021/11/25
- Re: [RFC] Moving to Guile 2.2 and away from GUB, David Kastrup, 2021/11/25
- Re: [RFC] Moving to Guile 2.2 and away from GUB, David Kastrup, 2021/11/25
- Re: [RFC] Moving to Guile 2.2 and away from GUB,
David Kastrup <=
- Re: [RFC] Moving to Guile 2.2 and away from GUB, David Kastrup, 2021/11/25
- Re: [RFC] Moving to Guile 2.2 and away from GUB, Jonas Hahnfeld, 2021/11/25
- Re: [RFC] Moving to Guile 2.2 and away from GUB, David Kastrup, 2021/11/25
- Re: [RFC] Moving to Guile 2.2 and away from GUB, Han-Wen Nienhuys, 2021/11/26
- Re: [RFC] Moving to Guile 2.2 and away from GUB, Jonas Hahnfeld, 2021/11/26
- Re: [RFC] Moving to Guile 2.2 and away from GUB, Han-Wen Nienhuys, 2021/11/27
- Re: [RFC] Moving to Guile 2.2 and away from GUB, Han-Wen Nienhuys, 2021/11/28
- Re: [RFC] Moving to Guile 2.2 and away from GUB, Jonas Hahnfeld, 2021/11/28
Re: [RFC] Moving to Guile 2.2 and away from GUB, Werner LEMBERG, 2021/11/24
Re: [RFC] Moving to Guile 2.2 and away from GUB, Jonas Hahnfeld, 2021/11/27