Ruby

Of course, while having some strange cache table entries would be pretty ok if they were not used (like it usually happens on x86_64). To make sure they are never used compiler should initialize the position field of the labels. I'm attaching a patch that does just that -- at least this makes segfaults irreproducible.

Could you show the backtrace?

Could you post a reproducer that reliably crashes Ruby?

I guess this is not really possible to crash Ruby reliably via this issue. Here is a reproducer that crashes on my MIPS32 LE machine one out of 20 times or so:

puts "BEGIN" if false begin require "some_mad_stuff" rescue LoadError puts "no mad stuff loaded" end end throw "foo" 

I'm attaching the interpreter output from one of the crashes.

As far as I understood, here's what happens. When "foo" is thrown from the last line of the reproducer, exception table is considered. The exception table contains only one entry. The start and end fields of the entry come from labels which position were never initialized, since the rescue block was removed before the compilation process reached iseq_set_sequence. So, the start and end fields of the cache table entry contain (somewhat processed) garbage from unitialized memory. Here are a few examples from machine where crush sometimes happens:

$ cat disasm.rb is = RubyVM::InstructionSequence.compile_file(ARGV[0]) puts is.disasm() $ for x in `seq 1 10`; do ruby disasm.rb test3.rb | grep ' rescue'; done | catch type: rescue st: 0000 ed: 0001 sp: -002 cont: 0000 | catch type: rescue st: 7168352 ed: 7168492 sp: -002 cont: 0000 | catch type: rescue st: 0000 ed: 0001 sp: -002 cont: 0000 | catch type: rescue st: 9085280 ed: 9085420 sp: -002 cont: 0000 | catch type: rescue st: 0000 ed: 0001 sp: -002 cont: 0000 | catch type: rescue st: 0000 ed: 0001 sp: -002 cont: 0000 | catch type: rescue st: 0000 ed: 0001 sp: -002 cont: 0000 | catch type: rescue st: 0000 ed: 0001 sp: -002 cont: 0000 | catch type: rescue st: 7070048 ed: 7070188 sp: -002 cont: 0000 | catch type: rescue st: 10264928 ed: 10265068 sp: -002 cont: 0000 

To actually crash Ruby, start should very close to 0, and end field should be large enough. In this case, Ruby considers the entry applicable and goes to the position cont field provides (which also comes from uninitialized memory), and sets sp to some very large value ( (usigned int) -1 or (usigned int) -2), and segfaults.

So whether Ruby crashes or not depends on the contents of the memory where labels are allocated by compile_rescue function. On my x86_64 machine it always has zeroes for some reason, so crashing Ruby on it is probably impossible. I'm just "lucky" to have a machine where this memory actually contains some garbage.

So whether Ruby crashes or not depends on the contents of the memory where labels are allocated by compile_rescue function.

And having position field of labels initialized (as in my attached patch) makes crash totally impossible.

Applied in changeset git|79d5332a2da0e2743a77480aebfca256a54a962e.

Drop eliminated catch-entries

Drop catch table entries used in eliminated block, as well as
call_infos. [Bug #16184]