summaryrefslogtreecommitdiff
path: root/ractor.c
diff options
context:
space:
mode:
authornagachika <nagachika@ruby-lang.org>2021-09-05 14:12:20 +0900
committernagachika <nagachika@ruby-lang.org>2021-09-05 14:12:20 +0900
commit3fb51aec5ba7decffdfc32e540262aaae6167a95 (patch)
tree2b7db8f9f92cbf740393113360e1c19016508f41 /ractor.c
parent911e75f0547ae3496280a731fbfd986096b0ffb6 (diff)
merge revision(s) bbedd29b6e98ef6e3fc2ce2b358d2b509b7cd1bb: [Backport #18117]
[Bug #18117] Fix Ractor race condition with GC rb_objspace_reachable_objects_from requires that the GC not be active. Since the Ractor barrier is not executed for incremental sweeping, Ractor may call rb_objspace_reachable_objects_from after sweeping has started to share objects. This causes a crash that looks like the following: ``` <internal:ractor>:627: [BUG] rb_objspace_reachable_objects_from() is not supported while during_gc == true ``` Co-authored-by: Vinicius Stock <vinicius.stock@shopify.com> --- bootstraptest/test_ractor.rb | 15 +++++++++++++++ ractor.c | 12 ++++++++++-- 2 files changed, 25 insertions(+), 2 deletions(-)
Diffstat (limited to 'ractor.c')
-rw-r--r--ractor.c12
1 files changed, 10 insertions, 2 deletions
diff --git a/ractor.c b/ractor.c
index df9cbc307a..7d6fec76e0 100644
--- a/ractor.c
+++ b/ractor.c
@@ -2325,7 +2325,11 @@ obj_traverse_i(VALUE obj, struct obj_traverse_data *data)
.stop = false,
.data = data,
};
- rb_objspace_reachable_objects_from(obj, obj_traverse_reachable_i, &d);
+ RB_VM_LOCK_ENTER_NO_BARRIER();
+ {
+ rb_objspace_reachable_objects_from(obj, obj_traverse_reachable_i, &d);
+ }
+ RB_VM_LOCK_LEAVE_NO_BARRIER();
if (d.stop) return 1;
}
break;
@@ -2635,7 +2639,11 @@ static int
obj_refer_only_shareables_p(VALUE obj)
{
int cnt = 0;
- rb_objspace_reachable_objects_from(obj, obj_refer_only_shareables_p_i, &cnt);
+ RB_VM_LOCK_ENTER_NO_BARRIER();
+ {
+ rb_objspace_reachable_objects_from(obj, obj_refer_only_shareables_p_i, &cnt);
+ }
+ RB_VM_LOCK_LEAVE_NO_BARRIER();
return cnt == 0;
}