From: normalperson@...
Date: 2014-12-19T21:18:30+00:00
Subject: [ruby-core:66988] [ruby-trunk - Feature #8543] rb_iseq_load

Issue #8543 has been updated by Eric Wong.


 I think the stack mismatches in current trunk are hard to avoid, but the
 loaded bytecode is still valid and runnable for the currently-skipped
 cases.  I propose the following to test more thoroughly.
 
 diff --git a/test/-ext-/iseq_load/test_iseq_load.rb b/test/-ext-/iseq_load/test_iseq_load.rb
 index 5bbd49e..7251603 100644
 --- a/test/-ext-/iseq_load/test_iseq_load.rb
 +++ b/test/-ext-/iseq_load/test_iseq_load.rb
 @@ -52,16 +52,21 @@ class TestIseqLoad < Test::Unit::TestCase
    end
  
    def test_next_in_block_in_block
 -    skip "failing due to stack_max mismatch"
 -    assert_iseq_roundtrip <<-'end;'
 -      3.times { 3.times { next } }
 +    @next_broke = false
 +    src = <<-'end;'
 +      3.times { 3.times { next; @next_broke = true } }
      end;
 +    a = ISeq.compile(src).to_a
 +    iseq = ISeq.iseq_load(a)
 +    iseq.eval
 +    assert_equal false, @next_broke
 +    skip "failing due to stack_max mismatch"
 +    assert_iseq_roundtrip(src)
    end
  
    def test_break_ensure
 -    skip "failing due to exception entry sp mismatch"
 -    assert_iseq_roundtrip <<-'end;'
 -      def m
 +    src = <<-'end;'
 +      def test_break_ensure_def_method
          bad = true
          while true
            begin
 @@ -70,8 +75,15 @@ class TestIseqLoad < Test::Unit::TestCase
              bad = false
            end
          end
 +        bad
        end
      end;
 +    a = ISeq.compile(src).to_a
 +    iseq = ISeq.iseq_load(a)
 +    iseq.eval
 +    assert_equal false, test_break_ensure_def_method
 +    skip "failing due to exception entry sp mismatch"
 +    assert_iseq_roundtrip(src)
    end
  
    # FIXME: still failing

----------------------------------------
Feature #8543: rb_iseq_load
https://bugs.ruby-lang.org/issues/8543#change-50519

* Author: Alexey Voskov
* Status: Closed
* Priority: Low
* Assignee: Koichi Sasada
* Category: YARV
* Target version: current: 2.2.0
----------------------------------------
I noticed an unusual behaviour of undocumented rb_iseq_load function. 
Its work differs in different Ruby versions. I'm trying to protect some Ruby
source code by its conversion to YARV p-code and using the next strategy:

1. Convert code to array

   ~~~ruby
   data = RubyVM::InstructionSequence.compile_file('hello.rb').to_a
   ~~~

2. Pass a compiled source to the rb_iseq_load function and evaluate it

   ~~~ruby
   iseq = iseq_load.(data)
   iseq.eval
   ~~~

Sample programs are supplied in the attachments.
"hello.rb"

```ruby
puts "tralivali"
def funct(a,b)
  a**b
end

3.times { |i|
  puts "Hello, world#{funct(2,i)}!"
}
```

The differences
Ruby 1.9.3 (ruby 1.9.3p194 (2012-04-20) [i386-mingw32])
Correct work. Output:

```
tralivali
Hello, world1!
Hello, world2!
Hello, world4!
```

Ruby 2.0.0 (ruby 2.0.0p193 (2013-05-14) [x64-mingw32])
Incorrect work (omits the code inside code blocks). Output

```
tralivali
```

Attempts of loading bigger programs by means of rb_iseq_load in Ruby 2.0.0 usually ends with a segmentation fault.

Such behaviour also can be reproduced by means of iseq Ruby extension ("for iseq freaks")
https://github.com/wanabe/iseq

P.S. I understand that it is an undocumented feature.


---Files--------------------------------
hello.rb (102 Bytes)
rb_pack.rb (931 Bytes)
iseq-load-test3.rb (210 Bytes)
iseq-load-test3-file.rb (369 Bytes)
please-fix-rb_iseq_load-thank-you.pdf (444 KB)


-- 
https://bugs.ruby-lang.org/