[ruby-core:66410] [ruby-trunk - Feature #8543] rb_iseq_load

From: normalperson@...
Date: 2014-11-22 08:28:27 UTC
List: ruby-core #66410
Issue #8543 has been updated by Eric Wong.


 billk@cts.com wrote:
 > But ultimately, the result of the manual bisect was:
 > 
 > 66d247bcb50a29769ff940100223544c125521aa is the first bad commit
 > commit 66d247bcb50a29769ff940100223544c125521aa
 > Author: ko1 <ko1@b2dd03c8-39d4-4d8f-98ff-823fe69b080e>
 > Date:   Tue Apr 24 09:20:42 2012 +0000
 > 
 >     * compile.c: fix to output warning when the same literals
 >       are available as a condition of same case clause.
 >       And remove infomation ('#n') because we can find duplicated
 >       condition with explicit line numbers.
 >       [ruby-core:38343] [Ruby 1.9 - Bug #5068]
 >     * test/ruby/test_syntax.rb: add a test for above.
 
 That was only one of the breakages :)
 Things have bitrotted a lot over the years.
 
 The following patch might be ready to commit to trunk:
 
    http://80x24.org/spew/m/rb_iseq_load_fix@v1.txt
 
 It's better than the complete breakage we have right now, so I might
 commit the above in a few days.  The new test case I added should
 help (or force) other core committers to maintain iseq loading,
 though.
 
 There's no public API change in this version of my patch.
 
 The test cases are probably not complete, though.  I am mainly
 interested in the feature because I'm working on another (in-core)
 optimization which may utilize this.
 
 I can definitely use some help thinking of better test cases since I
 don't believe I remember all of Ruby syntax :x

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

* Author: Alexey Voskov
* Status: Open
* 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/

In This Thread