gc.c: Fix a race condition in object_id
#13305
Conversation
This comment has been minimized.
This comment has been minimized.
|
So this fixes the obvious race, but there is a more fundamental issue that isn't and maybe can't be fixed. Prior to moving the Now that It's not great, but I'm afraid we may need to go back to a synchronized table to store object ids, at least in the case where the object is frozen and would need to be enlarged. |
474602d to
8055a1b
Compare
| obj_to_id_value = TypedData_Wrap_Struct(0, &obj_to_id_tbl_type, obj_to_id_tbl); | ||
| } | ||
| st_insert(obj_to_id_tbl, obj, id); | ||
| rb_shape_set_shape_id(obj, object_id_shape_id); |
There was a problem hiding this comment.
We're running into the same issue than #13289. If we on 32bits the shape_id is in the generic_ivar table...
If an object is shareable and has no capacity left, it isn't safe to store the object ID in fields as it requires an object resize which can't be done unless all field reads are synchronized. So in this case we have to store the ID externally like we used to.
8055a1b to
d202c39
Compare
| { | ||
| if (!tbl || tbl->num_entries == 0) return; | ||
|
|
||
| // FIXME: this certainly isn't correct. If a key moved, we need to re-hash. |
There was a problem hiding this comment.
Note: don't merge without addressing that.
| @@ -1940,12 +2018,12 @@ object_id(VALUE obj) | |||
|
|
|||
| if (UNLIKELY(rb_gc_multi_ractor_p() && rb_ractor_shareable_p(obj))) { | |||
There was a problem hiding this comment.
| if (UNLIKELY(rb_gc_multi_ractor_p() && rb_ractor_shareable_p(obj))) { | |
| if (UNLIKELY(rb_gc_multi_ractor_p() && RB_OBJ_SHAREABLE_P(obj))) { |
Faster and more restrictive check.
The shape was mistakenly accessed outside the lock.
cc @jhawthorn