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.
Correct.
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,
README.md 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/duration-scheme.cc b/lily/duration-scheme.cc
index 5d9b4447f1..6a09253adf 100644
--- a/lily/duration-scheme.cc
+++ b/lily/duration-scheme.cc
@@ -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;
else
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
something?
