Build CDHASH properly when loading iseq from binary
Before this change, CDHASH operands were built as plain hashes when
loaded from binary. Without setting up the hash with the correct
st_table type, the hash can sometimes be an ar_table. When the hash is
an ar_table, lookups can call the eql? method on keys of the hash,
which makes the opt_case_dispatch instruction not "leaf" as it
implicitly declares.
The following script trips the stack canary for checking the leaf
attribute for opt_case_dispatch on VM_CHECK_MODE > 0 (enabled by
default with RUBY_DEBUG).
rb_vm_iseq = RubyVM::InstructionSequence
iseq = rb_vm_iseq.compile(<<-EOF)
case Class.new(String).new("foo")
when "foo"
42
end
EOF
puts rb_vm_iseq.load_from_binary(iseq.to_binary).eval
This commit changes the binary loading logic to build CDHASH with the
right st_table type. The dumping logic and the dump format stays the
same
Build CDHASH properly when loading iseq from binary
Before this change, CDHASH operands were built as plain hashes when
loaded from binary. Without setting up the hash with the correct
st_table type, the hash can sometimes be an ar_table. When the hash is
an ar_table, lookups can call the
eql?
method on keys of the hash,which makes the
opt_case_dispatch
instruction not "leaf" as itimplicitly declares.
The following script trips the stack canary for checking the leaf
attribute for
opt_case_dispatch
on VM_CHECK_MODE > 0 (enabled bydefault with RUBY_DEBUG).
This commit changes the binary loading logic to build CDHASH with the
right st_table type. The dumping logic and the dump format stays the
same