Bug #19469
closed
Crash when resizing generic iv list
Added by peterzhu2118 (Peter Zhu) over 1 year ago.
Updated over 1 year ago.
Description
GitHub PR: https://github.com/ruby/ruby/pull/7407
The following script can sometimes trigger a crash:
GC.stress = true
class Array
def foo(bool)
if bool
@a = 1
@b = 2
@c = 1
else
@c = 1
end
end
end
obj = []
obj.foo(true)
obj2 = []
obj2.foo(false)
obj3 = []
obj3.foo(true)
This is because vm_setivar_default calls rb_ensure_generic_iv_list_size to resize the iv list. However, the call to gen_ivtbl_resize reallocs the iv list, and then inserts into the generic iv table. If the st_insert triggers a GC then the old iv list will be read during marking, causing a use-after-free bug.
Could this be the cause of #19433?
The stack traces seem to indicate generic IV table resizing.
- Status changed from Open to Closed
Applied in changeset git|62c2082f1f726cb90d8c332fbedbecf41d5d82ec.
[Bug #19469] Fix crash when resizing generic iv list
The following script can sometimes trigger a crash:
GC.stress = true
class Array
def foo(bool)
if bool
@a = 1
@b = 2
@c = 1
else
@c = 1
end
end
end
obj = []
obj.foo(true)
obj2 = []
obj2.foo(false)
obj3 = []
obj3.foo(true)
This is because vm_setivar_default calls rb_ensure_generic_iv_list_size
to resize the iv list. However, the call to gen_ivtbl_resize reallocs
the iv list, and then inserts into the generic iv table. If the
st_insert triggers a GC then the old iv list will be read during
marking, causing a use-after-free bug.
Co-Authored-By: Jemma Issroff jemmaissroff@gmail.com
- Related to Bug #19477: segfault during GC if ivars set on arrays added
- Related to Bug #19433: Segmentation fault in 3.2.0/3.2.1 on M1 Mac added
- Backport changed from 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED to 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONE
ruby_3_2 f3abe5ba645839fb2a686aee18d3466b59256af0 merged revision(s) 0700d0fd1c77b4fddf803dea3c10be654df600ff,62c2082f1f726cb90d8c332fbedbecf41d5d82ec.
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0