Bug #20501
closed
Added by akr (Akira Tanaka) 6 months ago.
Updated about 4 hours ago.
Description
I encountered SEGV of ruby.
% ./ruby -v
ruby 3.4.0dev (2024-05-22T06:59:19Z master 5613d6e95b) [x86_64-linux]
% ./ruby t.rb
t.rb:33: [BUG] Segmentation fault at 0x00007fc243696098
ruby 3.4.0dev (2024-05-22T06:59:19Z master 5613d6e95b) [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0003 p:0000 s:4294967313 e:000018 METHOD t.rb:33
c:0002 p:0022 s:0006 e:000005 EVAL t.rb:52 [FINISH]
c:0001 p:0000 s:0003 E:000350 DUMMY [FINISH]
-- Ruby level backtrace information ----------------------------------------
t.rb:52:in '<main>'
t.rb:33:in 'create_no_file'
-- Threading information ---------------------------------------------------
Total ractor count: 1
Ruby thread count for this ractor: 1
-- Machine register context ------------------------------------------------
RIP: 0x000055a1cdc8bb9c RBP: 0x000055a1cee844b0 RSP: 0x00007ffcde5cdae0
RAX: 0x00007fc2436960a0 RBX: 0x00007fba43795f68 RCX: 0x0000000000000000
RDX: 0x000055a1cf115cf0 RDI: 0x0000000000000009 RSI: 0x00007fba28526860
R8: 0x00007fba436960a1 R9: 0x0000000000000000 R10: 0x00007fba28526860
R11: 0x0000000000000003 R12: 0x0000000000000006 R13: 0x00007fba2853b698
R14: 0x0000000d00000009 R15: 0x0000000000000b21 EFL: 0x0000000000010246
-- C level backtrace information -------------------------------------------
/home/ruby/t2/ruby/ruby(rb_print_backtrace+0x14) [0x55a1cdcae243] /home/ruby/t2/ruby/vm_dump.c:820
/home/ruby/t2/ruby/ruby(rb_vm_bugreport) /home/ruby/t2/ruby/vm_dump.c:1151
/home/ruby/t2/ruby/ruby(rb_bug_for_fatal_signal+0xf8) [0x55a1cde5abe8] /home/ruby/t2/ruby/error.c:1108
/home/ruby/t2/ruby/ruby(sigsegv+0x44) [0x55a1cdbf7864] /home/ruby/t2/ruby/signal.c:929
/lib/x86_64-linux-gnu/libc.so.6(0x7fba438f8050) [0x7fba438f8050]
/home/ruby/t2/ruby/ruby(vm_exec_handle_exception+0x2ac) [0x55a1cdc8bb9c] /home/ruby/t2/ruby/vm.c:2782
...
t.rb
and the full crash report are attached.
Files
t.rb
is not minimized because the probability of SEGV is reduced when I make the file smaller.
Although I can't reproduce it, it looks like that catch_iseq
is broken, from the backtrace.
git bisect shows the problem is caused by the following commit.
% git bisect bad
84e4453436c3549b4fda6014cdd5fcc9e0b80755 is the first bad commit
commit 84e4453436c3549b4fda6014cdd5fcc9e0b80755
Author: Aaron Patterson <tenderlove@ruby-lang.org>
Date: Tue Feb 7 17:46:42 2023 -0800
Use a functional red-black tree for indexing the shapes
This is an experimental commit that uses a functional red-black tree to
create an index of the ancestor shapes. It uses an Okasaki style
functional red black tree:
https://www.cs.tufts.edu/comp/150FP/archive/chris-okasaki/redblack99.pdf
This tree is advantageous because:
* It offers O(n log n) insertions and O(n log n) lookups.
* It shares memory with previous "versions" of the tree
When we insert a node in the tree, only the parts of the tree that need
to be rebalanced are newly allocated. Parts of the tree that don't need
to be rebalanced are not reallocated, so "new trees" are able to share
memory with old trees. This is in contrast to a sorted set where we
would have to duplicate the set, and also resort the set on each
insertion.
I've added a new stat to RubyVM.stat so we can understand how the red
black tree increases.
benchmark/vm_ivar_ic_miss.yml | 20 +++
rjit_c.rb | 5 +
shape.c | 309 ++++++++++++++++++++++++++++++++++++++++--
shape.h | 15 ++
vm.c | 8 +-
5 files changed, 342 insertions(+), 15 deletions(-)
create mode 100644 benchmark/vm_ivar_ic_miss.yml
% ./miniruby -v
ruby 3.3.0dev (2023-10-24T17:52:06Z v3_3_0_preview3~561 84e4453436) [x86_64-linux]
% ./miniruby t.rb
t.rb:32593: [BUG] Segmentation fault at 0x00007f596f3e1098
ruby 3.3.0dev (2023-10-24T17:52:06Z v3_3_0_preview3~561 84e4453436) [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0003 p:21907 s:4294967313 e:000018 METHOD t.rb:32593
c:0002 p:0022 s:0006 e:000005 EVAL t.rb:52 [FINISH]
c:0001 p:0000 s:0003 E:001b90 DUMMY [FINISH]
-- Ruby level backtrace information ----------------------------------------
t.rb:52:in `<main>'
t.rb:32593:in `create_no_file'
-- Threading information ---------------------------------------------------
Total ractor count: 1
Ruby thread count for this ractor: 1
-- Machine register context ------------------------------------------------
RIP: 0x0000559323b21d31 RBP: 0x00007ffd7d3f5730 RSP: 0x00007ffd7d3f55e0
RAX: 0x00007f596f3e1098 RBX: 0x00007f51542a27c0 RCX: 0x00007f516f4e0f30
RDX: 0x00007f51542a27c0 RDI: 0x00007f516f3e10a0 RSI: 0x0000000000000080
R8: 0x00000000000005f5 R9: 0x0000559325ad6220 R10: 0x06c15729dbba7803
R11: 0x0000000000000090 R12: 0x00007f516f3e1040 R13: 0x0000000000000000
R14: 0x000055932591c490 R15: 0x00007f516f4e0f30 EFL: 0x0000000000010206
-- C level backtrace information -------------------------------------------
/home/ruby/t4/ruby/miniruby(rb_print_backtrace+0x20) [0x559323b2be67] /home/ruby/t4/ruby/vm_dump.c:812
/home/ruby/t4/ruby/miniruby(rb_vm_bugreport+0x28c) [0x559323b2c57e] /home/ruby/t4/ruby/vm_dump.c:1143
./miniruby(rb_bug_for_fatal_signal+0x143) [0x559323906dd1]
/home/ruby/t4/ruby/miniruby(sigsegv+0x75) [0x559323a70ced] /home/ruby/t4/ruby/signal.c:920
/home/ruby/t4/ruby/miniruby(sigill) (null):0
/lib/x86_64-linux-gnu/libc.so.6(0x7f516f641050) [0x7f516f641050]
/home/ruby/t4/ruby/miniruby(vm_exec_handle_exception+0xb18) [0x559323b21d31] /home/ruby/t4/ruby/vm.c:2687
...
The full crash log is attached as crash2.txt.
- Status changed from Open to Assigned
- Assignee set to tenderlovemaking (Aaron Patterson)
It looks like it has to do with defined?()
in an if
expression and its catch table entries when the first part of the if expression has been eliminated and there is no then label to follow.
For example, this is a minimal reproduction:
def my_method
ivar = nil # seems to be needed to reproduce the issue
if false && defined? File::TMPFILE
end
raise "woops"
end
my_method
The defined
catch table entry is not setup correctly in this case.
I only tried this on ruby head, but I get a segfault.
luke-gru (Luke Gruber) wrote in #note-5:
For example, this is a minimal reproduction:
I can't reproduce it with master.
def my_method
ivar = nil # seems to be needed to reproduce the issue
if false && defined? File::TMPFILE
end
raise "woops"
end
my_method
$ ./bin/ruby -v bug-20501.rb
ruby 3.4.0dev (2024-09-06T00:32:47Z master 81b74c9fad) [aarch64-linux]
bug-20501.rb:2: warning: assigned but unused variable - ivar
bug-20501.rb:5:in 'Object#my_method': woops (RuntimeError)
from bug-20501.rb:7:in '<main>'
$ ./ruby -v bug-20501.rb
ruby 3.4.0dev (2024-09-06T00:32:47Z master 81b74c9fad) [arm64-darwin23]
bug-20501.rb:2: warning: assigned but unused variable - ivar
bug-20501.rb:5:in 'Object#my_method': woops (RuntimeError)
from bug-20501.rb:7:in '<main>'
I'm on x86-64 linux so that might have to do with it. I'll investigate a bit more.
I'm not able to reproduce on Linux with this script using either master HEAD or 5613d6e95b.
This is a weird way to reproduce, but you can see it on https://runruby.dev/ if you comment out the Gemfile and put this in main.rb:
def my_method
var = nil
if false && defined? File::TMPFILE
end
raise "woops"
end
puts RubyVM::InstructionSequence.disasm(method(:my_method)) # you should see the invalid catch table entry in the disasm bytecode
my_method() # if this doesn't trigger an error, try running it multiple times.
Okay, I figured out what's happening. In compile.c, new LABELs are allocated from an arena, and this is using xmalloc, so it's not zeroed. Labels have a position
field that is not set in the new_label_body()
function, so it could be zeroed or not depending on many things of course. When compiling the defined
after a known compile-time false value, its labels are NOT added to the anchor, and so its position is not set during iseq_set_sequence
in iseq_setup
, but it is saved to the iseq's catch_table_ary
. Then, during iseq_set_exception_table
, the iseq_catch_table_entry
's start
and end
are set to the LABEL's position
because the LABEL is inside the iseq's catch_table_ary
. There is no check for garbage values, which would be negative in this case, as position
is an int. The iseq_catch_table_entry
takes this possibly garbage value and saves it as its start
and end
.
I've updated my PR and added some assertions to the code to make sure this doesn't happen elsewhere.
These issues don't appear on current ruby master because prism is the new parser/compiler and it only affects the parse.y parser/compiler.
- Status changed from Assigned to Closed
- Backport changed from 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN to 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED
I'm not sure but this seems to need to be backported.
- Backport changed from 3.1: REQUIRED, 3.2: REQUIRED, 3.3: REQUIRED to 3.1: WONTFIX, 3.2: WONTFIX, 3.3: REQUIRED
While trying to backport d592ddd5e619ffe1691b8050de2ccc3e1bd6e080 to ruby_3_2, I found that it depends on 6e64d4370456190541705ec4c6cf3af6bf4ac647 (for [Bug #19862]). And I cannot reproduce the SEGV on rub-3.2.
I decided to set WONTFIX for 3.1/3.2.
Please tell us if you found it can be reproduced on 3.2.
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0