From: billk@cts.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:66446] [ruby-trunk - Feature #8543] rb_iseq_load
Date: Mon, 24 Nov 2014 23:13:15 +0000 [thread overview]
Message-ID: <redmine.journal-50071.20141124231314.fa35c657232e904c@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-8543.20130619213935@ruby-lang.org
Issue #8543 has been updated by B Kelly.
Howdy,
Eric Wong wrote:
> 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.
Thanks so much for working on this.
Just some initial feedback -- after applying both patches to trunk,
I'm still seeing a segfault in the iseq.eval call on iseq-load-test3.rb,
though in a different location than before.
ci->kw_arg 00000000
ci->kw_arg 00000000
ci->kw_arg 00000000
ci->kw_arg 00000000
ci->kw_arg 00000000
ci->kw_arg 00000000
ci->kw_arg 00000000
ci->kw_arg 00000000
omg: {:mid=>:each_char, :flag=>256, :orig_argc=>0, :blockptr=>nil}
omg: {:mid=>:inject, :flag=>0, :orig_argc=>1, :blockptr=>["YARVInstructionSequence/SimpleDataFormat", 2, 2, 1, {:arg_size=>2, :local_size=>3, :stack_max=>4}, "block in user_mask", "./iseq-load-test3-file.rb", "P:/code/ruby/bkelly/test/iseq-load-test3-file.rb", 4, :block, [:mask, :chr], {:lead_num=>2}, [[:redo, nil, :label_2, :label_102, :label_2, 0], [:next, nil, :label_2, :label_102, :label_102, 0]], [4, [:trace, 256], :label_2, 5, [:trace, 1], [:getlocal_OP__WC__0, 2], [:dup], [:opt_case_dispatch, ["u", :label_60, "g", :label_71, "o", :label_82, "a", :label_93], :label_38], 6, [:dup], [:putobject, "u"], [:checkmatch, 2], [:branchif, :label_60], 8, [:dup], [:putobject, "g"], [:checkmatch, 2], [:branchif, :label_71], 10, [:dup], [:putobject, "o"], [:checkmatch, 2], [:branchif, :label_82], 12, [:dup], [:putobject, "a"], [:checkmatch, 2], [:branchif, :label_93], :label_38, 15, [:pop], [:trace, 1], [:putself], [:getinlinecache, :label_49, 0], [:getconstant, :ArgumentError], [:se
tinlinecache, 0], :label_49, [:putobject, "invalid `who' symbol in file mode: "], [:getlocal_OP__WC__0, 2], [:tostring], [:concatstrings, 2], [:opt_send_without_block, {:mid=>:raise, :flag=>264, :orig_argc=>2, :blockptr=>nil}], [:jump, :label_102], :label_60, 16, [:pop], 7, [:trace, 1], [:getlocal_OP__WC__0, 3], [:putobject, 2496], [:opt_send_without_block, {:mid=>:|, :flag=>256, :orig_argc=>1, :blockptr=>nil}], 16, [:jump, :label_102], :label_71, [:pop], 9, [:trace, 1], [:getlocal_OP__WC__0, 3], [:putobject, 1080], [:opt_send_without_block, {:mid=>:|, :flag=>256, :orig_argc=>1, :blockptr=>nil}], 16, [:jump, :label_102], :label_82, [:pop], 11, [:trace, 1], [:getlocal_OP__WC__0, 3], [:putobject, 519], [:opt_send_without_block, {:mid=>:|, :flag=>256, :orig_argc=>1, :blockptr=>nil}], 16, [:jump, :label_102], :label_93, [:pop], 13, [:trace, 1], [:getlocal_OP__WC__0, 3], [:putobject, 4095], [:opt_send_without_block, {:mid=>:|, :flag=>256, :orig_argc=>1, :blockptr=>nil}], :label_1
02, 17, [:trace, 512], 15, [:leave]]]}
omg: {:mid=>:"core#define_method", :flag=>256, :orig_argc=>3, :blockptr=>nil}
./iseq-load-test3-file.rb:3:in `<module:FileUtils>'iseq-load-test3.rb: [BUG] Segmentation fault
ruby 2.2.0dev (2014-11-24 trunk 48553) [i386-mswin32_100]
-- Control frame information -----------------------------------------------
c:0005 p:---- s:0010 e:000009 CFUNC :to_s
c:0004 p:---- s:0008 e:000007 CFUNC :to_str
c:0003 p:---- s:0006 e:000005 CFUNC :to_s
c:0002 p:---- s:0004 e:000003 CFUNC :message
c:0001 p:0000 s:0002 E:000f5c TOP [FINISH]
-- Ruby level backtrace information ----------------------------------------
iseq-load-test3.rb:0:in `message'
iseq-load-test3.rb:0:in `to_s'
iseq-load-test3.rb:0:in `to_str'
iseq-load-test3.rb:0:in `to_s'
-- C level backtrace information -------------------------------------------
C:\Windows\SysWOW64\ntdll.dll(ZwWaitForSingleObject+0x15) [0x76EAF8D1]
C:\Windows\syswow64\kernel32.dll(WaitForSingleObjectEx+0x43) [0x76511194]
C:\Windows\syswow64\kernel32.dll(WaitForSingleObject+0x12) [0x76511148]
M:\dev\ruby-build\trunk\bin\msvcr100-ruby220.dll(rb_print_backtrace+0x38) [0x52AD8468] p:\code\ruby-git\ruby-trunk\vm_dump.c:712
M:\dev\ruby-build\trunk\bin\msvcr100-ruby220.dll(rb_vm_bugreport+0x65) [0x52AD8915] p:\code\ruby-git\ruby-trunk\vm_dump.c:974
M:\dev\ruby-build\trunk\bin\msvcr100-ruby220.dll(rb_bug_context+0x74) [0x529D24F4] p:\code\ruby-git\ruby-trunk\error.c:389
M:\dev\ruby-build\trunk\bin\msvcr100-ruby220.dll(sigsegv+0x28) [0x52A5D638] p:\code\ruby-git\ruby-trunk\signal.c:850
C:\Windows\system32\MSVCR100.dll(XcptFilter+0x13e) [0x71B5B9DF]
M:\dev\ruby-build\trunk\bin\ruby_t.exe(__tmainCRTStartup+0x14a) [0x00DD11F5] f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c:572
C:\Windows\system32\MSVCR100.dll(seh_longjmp_unwind4+0x2e) [0x71AD2F54]
C:\Windows\syswow64\kernel32.dll(BaseThreadInitThunk+0x12) [0x7651338A]
C:\Windows\SysWOW64\ntdll.dll(RtlInitializeExceptionChain+0x63) [0x76EC9F72]
-- Other runtime information -----------------------------------------------
* Loaded script: iseq-load-test3.rb
The debugger backtrace was:
msvcr100-ruby220.dll!str_replace_shared_without_enc(unsigned long str2=0x02ea1990, unsigned long str=0x00000000) Line 874 + 0x3 bytes C
msvcr100-ruby220.dll!str_replace_shared(unsigned long str2=0x02ea1990, unsigned long str=0x00000000) Line 892 + 0xd bytes C
msvcr100-ruby220.dll!str_new_shared(unsigned long klass=0x0024e76c, unsigned long str=0x00000000) Line 900 + 0x16 bytes C
msvcr100-ruby220.dll!rb_sym_to_s(unsigned long sym=0x0000000e) Line 8599 + 0x19 bytes C
msvcr100-ruby220.dll!call_cfunc_0(unsigned long (void)* func=0x52254cd0, unsigned long recv=0x0000000e, int argc=0x00000000, const unsigned long * argv=0x00000000) Line 1193 + 0x7 bytes C
msvcr100-ruby220.dll!vm_call0_cfunc_with_frame(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004ceadc, const unsigned long * argv=0x00000000) Line 127 + 0x1a bytes C
msvcr100-ruby220.dll!vm_call0_cfunc(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004ceadc, const unsigned long * argv=0x00000000) Line 144 + 0x11 bytes C
msvcr100-ruby220.dll!vm_call0_body(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004ceadc, const unsigned long * argv=0x00000000) Line 184 + 0x11 bytes C
msvcr100-ruby220.dll!vm_call0(rb_thread_struct * th=0x002ab438, unsigned long recv=0x0000000e, unsigned long id=0x00000ca1, int argc=0x00000000, const unsigned long * argv=0x00000000, const rb_method_entry_struct * me=0x0027b118, unsigned long defined_class=0x0024e0a0) Line 59 + 0x11 bytes C
msvcr100-ruby220.dll!rb_call0(unsigned long recv=0x0000000e, unsigned long mid=0x00000ca1, int argc=0x00000000, const unsigned long * argv=0x00000000, call_type scope=CALL_FCALL, unsigned long self=0x02ea1abc) Line 348 + 0x21 bytes C
msvcr100-ruby220.dll!rb_call(unsigned long recv=0x0000000e, unsigned long mid=0x00000ca1, int argc=0x00000000, const unsigned long * argv=0x00000000, call_type scope=CALL_FCALL) Line 610 + 0x23 bytes C
msvcr100-ruby220.dll!rb_funcall(unsigned long recv=0x0000000e, unsigned long mid=0x00000ca1, int n=0x00000000, ...) Line 812 + 0x17 bytes C
msvcr100-ruby220.dll!rb_obj_as_string(unsigned long obj=0x0000000e) Line 1111 + 0x12 bytes C
msvcr100-ruby220.dll!rb_str_format(int argc=0x00000003, const unsigned long * argv=0x004cef90, unsigned long fmt=0x02ea19b8) Line 711 + 0xc bytes C
msvcr100-ruby220.dll!rb_f_sprintf(int argc=0x00000003, const unsigned long * argv=0x004cef90) Line 449 + 0x3e bytes C
msvcr100-ruby220.dll!name_err_mesg_to_str(unsigned long obj=0x02ea3330) Line 1204 + 0xb bytes C
msvcr100-ruby220.dll!call_cfunc_0(unsigned long (void)* func=0x522142d0, unsigned long recv=0x02ea1abc, int argc=0x00000000, const unsigned long * argv=0x00000000) Line 1193 + 0x7 bytes C
msvcr100-ruby220.dll!vm_call0_cfunc_with_frame(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004cf0f0, const unsigned long * argv=0x00000000) Line 127 + 0x1a bytes C
msvcr100-ruby220.dll!vm_call0_cfunc(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004cf0f0, const unsigned long * argv=0x00000000) Line 144 + 0x11 bytes C
msvcr100-ruby220.dll!vm_call0_body(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004cf0f0, const unsigned long * argv=0x00000000) Line 184 + 0x11 bytes C
msvcr100-ruby220.dll!vm_call0(rb_thread_struct * th=0x002ab438, unsigned long recv=0x02ea1abc, unsigned long id=0x00000c41, int argc=0x00000000, const unsigned long * argv=0x00000000, const rb_method_entry_struct * me=0x0027ef38, unsigned long defined_class=0x0024dbb4) Line 59 + 0x11 bytes C
msvcr100-ruby220.dll!rb_check_funcall(unsigned long recv=0x02ea1abc, unsigned long mid=0x00000c41, int argc=0x00000000, const unsigned long * argv=0x00000000) Line 449 + 0x21 bytes C
msvcr100-ruby220.dll!convert_type(unsigned long val=0x02ea1abc, const char * tname=0x523fe264, const char * method=0x523fe25c, int raise=0x00000000) Line 2623 + 0x11 bytes C
msvcr100-ruby220.dll!rb_check_convert_type(unsigned long val=0x02ea1abc, int type=0x00000005, const char * tname=0x523fe264, const char * method=0x523fe25c) Line 2673 + 0x13 bytes C
msvcr100-ruby220.dll!rb_check_string_type(unsigned long str=0x02ea1abc) Line 1744 + 0x15 bytes C
msvcr100-ruby220.dll!rb_String(unsigned long val=0x02ea1abc) Line 3022 + 0x9 bytes C
msvcr100-ruby220.dll!exc_to_s(unsigned long exc=0x02ea1a94) Line 693 + 0x9 bytes C
msvcr100-ruby220.dll!call_cfunc_0(unsigned long (void)* func=0x52213b10, unsigned long recv=0x02ea1a94, int argc=0x00000000, const unsigned long * argv=0x00000000) Line 1193 + 0x7 bytes C
msvcr100-ruby220.dll!vm_call0_cfunc_with_frame(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004cf348, const unsigned long * argv=0x00000000) Line 127 + 0x1a bytes C
msvcr100-ruby220.dll!vm_call0_cfunc(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004cf348, const unsigned long * argv=0x00000000) Line 144 + 0x11 bytes C
msvcr100-ruby220.dll!vm_call0_body(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004cf348, const unsigned long * argv=0x00000000) Line 184 + 0x11 bytes C
msvcr100-ruby220.dll!vm_call0(rb_thread_struct * th=0x002ab438, unsigned long recv=0x02ea1a94, unsigned long id=0x00000ca1, int argc=0x00000000, const unsigned long * argv=0x00000000, const rb_method_entry_struct * me=0x0027bbb8, unsigned long defined_class=0x0024e028) Line 59 + 0x11 bytes C
msvcr100-ruby220.dll!rb_call0(unsigned long recv=0x02ea1a94, unsigned long mid=0x00000ca1, int argc=0x00000000, const unsigned long * argv=0x00000000, call_type scope=CALL_FCALL, unsigned long self=0x02ea1a94) Line 348 + 0x21 bytes C
msvcr100-ruby220.dll!rb_call(unsigned long recv=0x02ea1a94, unsigned long mid=0x00000ca1, int argc=0x00000000, const unsigned long * argv=0x00000000, call_type scope=CALL_FCALL) Line 610 + 0x23 bytes C
msvcr100-ruby220.dll!rb_funcall(unsigned long recv=0x02ea1a94, unsigned long mid=0x00000ca1, int n=0x00000000, ...) Line 812 + 0x17 bytes C
msvcr100-ruby220.dll!exc_message(unsigned long exc=0x02ea1a94) Line 709 + 0x1b bytes C
msvcr100-ruby220.dll!call_cfunc_0(unsigned long (void)* func=0x52213be0, unsigned long recv=0x02ea1a94, int argc=0x00000000, const unsigned long * argv=0x00000000) Line 1193 + 0x7 bytes C
msvcr100-ruby220.dll!vm_call0_cfunc_with_frame(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004cf580, const unsigned long * argv=0x00000000) Line 127 + 0x1a bytes C
msvcr100-ruby220.dll!vm_call0_cfunc(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004cf580, const unsigned long * argv=0x00000000) Line 144 + 0x11 bytes C
msvcr100-ruby220.dll!vm_call0_body(rb_thread_struct * th=0x002ab438, rb_call_info_struct * ci=0x004cf580, const unsigned long * argv=0x00000000) Line 184 + 0x11 bytes C
msvcr100-ruby220.dll!vm_call0(rb_thread_struct * th=0x002ab438, unsigned long recv=0x02ea1a94, unsigned long id=0x00001c61, int argc=0x00000000, const unsigned long * argv=0x00000000, const rb_method_entry_struct * me=0x0027bc38, unsigned long defined_class=0x0024e028) Line 59 + 0x11 bytes C
msvcr100-ruby220.dll!rb_check_funcall(unsigned long recv=0x02ea1a94, unsigned long mid=0x00001c61, int argc=0x00000000, const unsigned long * argv=0x00000000) Line 449 + 0x21 bytes C
msvcr100-ruby220.dll!error_print() Line 133 + 0x25 bytes C
msvcr100-ruby220.dll!error_handle(int ex=0x00000006) Line 312 C
msvcr100-ruby220.dll!ruby_cleanup(volatile int ex=0x00000006) Line 193 + 0x9 bytes C
msvcr100-ruby220.dll!ruby_run_node(void * n=0x02e55234) Line 309 + 0x12 bytes C
ruby_t.exe!main(int argc=0x00000002, char * * argv=0x002a1678) Line 36 + 0x16 bytes C
ruby_t.exe!__tmainCRTStartup() Line 555 + 0x17 bytes C
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
ntdll.dll!___RtlUserThreadStart@8() + 0x27 bytes
ntdll.dll!__RtlUserThreadStart@8() + 0x1b bytes
It seemed to be dying in an rb_f_sprintf() call. The 'desc' variable in
name_err_mesg_to_str(), which was invoking sprintf, evaluated to:
desc = 0x02e11420 "<RubyVM::InstructionSequence:user_mask@./iseq-load-test3-file.rb>"
If there's anything I could try that might help narrow it down further,
please let me know.
Thanks again for your help,
Bill
----------------------------------------
Feature #8543: rb_iseq_load
https://bugs.ruby-lang.org/issues/8543#change-50071
* 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/
next prev parent reply other threads:[~2014-11-24 23:23 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-19 12:39 [ruby-core:55557] [ruby-trunk - misc #8543][Open] rb_iseq_load alvoskov (Alexey Voskov)
2013-06-20 7:40 ` [ruby-core:55568] [ruby-trunk - Bug #8543] rb_iseq_load nagachika (Tomoyuki Chikanaga)
2014-01-30 6:17 ` [ruby-core:60299] " shibata.hiroshi
2014-04-16 8:25 ` [ruby-core:62050] " billk
2014-04-16 10:21 ` [ruby-core:62052] " billk
2014-06-26 23:40 ` [ruby-core:63353] " billk
2014-06-30 8:07 ` [ruby-core:63427] " naruse
2014-07-26 5:42 ` [ruby-core:64033] " ko1
2014-07-26 5:46 ` [ruby-core:64034] [ruby-trunk - Feature " nobu
2014-10-09 7:18 ` [ruby-core:65555] " billk
2014-10-09 7:44 ` [ruby-core:65556] " Eric Wong
2014-10-09 7:51 ` [ruby-core:65557] " normalperson
2014-10-09 23:44 ` [ruby-core:65574] " billk
2014-11-22 0:03 ` [ruby-core:66402] " Eric Wong
2014-11-22 1:06 ` [ruby-core:66404] " Eric Wong
2014-11-22 8:19 ` [ruby-core:66409] " Eric Wong
2014-11-23 5:56 ` [ruby-core:66423] " Eric Wong
2014-11-22 0:08 ` [ruby-core:66403] " normalperson
2014-11-22 1:08 ` [ruby-core:66405] " normalperson
2014-11-22 8:28 ` [ruby-core:66410] " normalperson
2014-11-23 5:58 ` [ruby-core:66424] " normalperson
2014-11-24 23:13 ` billk [this message]
2014-11-25 2:01 ` [ruby-core:66450] " Eric Wong
2014-11-25 2:08 ` [ruby-core:66451] " normalperson
2014-11-25 3:09 ` [ruby-core:66452] " billk
2014-11-25 8:19 ` [ruby-core:66456] " ko1
2014-11-26 1:38 ` [ruby-core:66465] " Eric Wong
2014-11-26 1:48 ` [ruby-core:66467] " normalperson
2014-11-26 6:49 ` [ruby-core:66472] " ko1
2014-11-26 8:09 ` [ruby-core:66476] " Eric Wong
2014-11-26 8:18 ` [ruby-core:66478] " normalperson
2014-11-27 3:02 ` [ruby-core:66508] " Eric Wong
2014-11-27 3:08 ` [ruby-core:66510] " normalperson
2014-11-29 11:55 ` [ruby-core:66566] " s.wanabe
2014-12-01 22:35 ` [ruby-core:66633] " Eric Wong
2014-12-01 22:38 ` [ruby-core:66634] " normalperson
2014-12-19 21:15 ` [ruby-core:66987] " Eric Wong
2014-12-19 21:18 ` [ruby-core:66988] " normalperson
2015-09-09 23:27 ` [ruby-core:70708] [Ruby trunk - Feature #8543] new rb_iseq_load crash billk
2015-09-10 0:09 ` [ruby-core:70709] " billk
2015-09-10 14:12 ` [ruby-core:70711] [Ruby trunk - Bug " nagachika00
2015-09-10 16:42 ` [ruby-core:70713] " Bill Kelly
2015-09-10 16:54 ` [ruby-core:70714] " U.NAKAMURA
2015-09-10 17:14 ` [ruby-core:70715] " Bill Kelly
2015-09-11 1:35 ` [ruby-core:70722] " Nobuyoshi Nakada
2015-11-24 15:43 ` [ruby-core:71653] " nagachika00
2015-12-08 3:11 ` [ruby-core:71930] " usa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.ruby-lang.org/en/community/mailing-lists/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=redmine.journal-50071.20141124231314.fa35c657232e904c@ruby-lang.org \
--to=ruby-core@ruby-lang.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).