[Top][All Lists]

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

Re: GC and simple smobs??

From: Jean Abou Samra
Subject: Re: GC and simple smobs??
Date: Tue, 21 Jun 2022 13:06:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

Le 17/06/2022 à 23:46, David Kastrup a écrit :
Since they are pointers to the part of the SCM that stores the C++
object, and not to the start of the SCM value, they won't cause the
SCM to be marked by their mere existence on the stack.

Actually, I believe that we were both wrong. It was definitely correct
in Guile 1, or commits like 0448210202 would not have been needed. However, from BDWGC says

Any objects not intended to be collected must be pointed to either
from other such accessible objects, or from the registers,
stack, data, or statically allocated bss segments.  Pointers from
the stack or registers may point to anywhere inside an object.
The same is true for heap pointers if the collector is compiled with
`ALL_INTERIOR_POINTERS` defined, or `GC_all_interior_pointers` is otherwise
set, as is now the default.

Guile does GC_set_all_interior_pointers (0), so in our case
it does not work for pointers on the heap, such as a smob
pointer as a member in a C++ engraver, but it would apparently
work for local variables on the stack.

To check that, I applied

diff --git a/lily/ b/lily/
index 5d9b4447f1..6a09253adf 100644
--- a/lily/
+++ b/lily/
@@ -45,6 +45,8 @@ Is @var{p1} shorter than @var{p2}?
   auto *const a = LY_ASSERT_SMOB (Duration, p1, 1);
   auto *const b = LY_ASSERT_SMOB (Duration, p2, 2);

+  scm_gc ();
   if (Duration::compare (*a, *b) < 0)
     return SCM_BOOL_T;

and compiled

#(do ((i 0 (1+ i)))
   ((= i 100))
   (ly:duration<? #{ 4 #} #{ 8 #}))

No crashes observed.

If I am understanding this correctly, a source of possible GC
crashes went away in the Guile 2 transition. Or am I missing

reply via email to

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