diff options
| author | John Hawthorn <john@hawthorn.email> | 2025-11-04 17:15:59 -0800 |
|---|---|---|
| committer | John Hawthorn <john@hawthorn.email> | 2025-11-20 14:05:00 -0800 |
| commit | 9b87a0b9b667ce12e9e6245d4eda40b5dfdeb5f9 (patch) | |
| tree | 421dbe52906b3ed258f2900b46141508d43b57e2 /class.c | |
| parent | a4a99a24e8299f9595cb41591f3252e6082d744f (diff) | |
Fix missing write barrier on namespace classext
Found by wbcheck
It seems like here the classext was associated with the class, but it
already had Ruby objects attached.
rb_gc_writebarrier_remember works around that issue, but I suspect if we
enabled autocompaction the values copied into the classext before it was
attached could be broken.
Diffstat (limited to 'class.c')
| -rw-r--r-- | class.c | 6 |
1 files changed, 6 insertions, 0 deletions
@@ -183,6 +183,12 @@ rb_class_set_box_classext(VALUE obj, const rb_box_t *box, rb_classext_t *ext) }; st_update(RCLASS_CLASSEXT_TBL(obj), (st_data_t)box->box_object, rb_class_set_box_classext_update, (st_data_t)&args); + + // FIXME: This is done here because this is the first time the objects in + // the classext are exposed via this class. It's likely that if GC + // compaction occurred between the VALUEs being copied in and this + // writebarrier trigger the values will be stale. + rb_gc_writebarrier_remember(obj); } RUBY_EXTERN rb_serial_t ruby_vm_global_cvar_state; |
