Backport #8879: String#to_r fails after moving ruby to other OSX system

• Status: Closed
• Priority: Normal
• Assignee: nagachika (Tomoyuki Chikanaga)

[mpapis (Michal Papis)]

=begin
I got reported by users ((())) that a static binary compiled for OSX after moving to other system fails for the method (({String#to_r})):
ruby -e 'puts ".8".to_r'
0
The same binary checked on the build system produces proper result:
ruby -e 'puts ".8".to_r'
4/5
Also the same version compiled from source on the target system produces proper result:
ruby -e 'puts ".8".to_r'
4/5
Please help me debug the problem, can it be related to compilation with (({clang}))?
=end

[nagachika (Tomoyuki Chikanaga)]

• Status changed from Open to Feedback

Hello,

I cannot reproduce this (transfer binary compiled on an environment (darwin 12.4.0/x86_64/clang-425.0.28(based on LLVM 3.2svn)) to another (dawrin 12.4.0/x86_64).

We need more information.
Cf) clang version, OS X version and architecture on both system, configure options. What's happen when compiled with optimization level (-O0) etc...

Regards.

[mpapis (Michal Papis)]

can you try with this binary: http://rvm.io/binaries/osx/10.8/x86_64/ruby-2.0.0-p247.tar.bz2

both systems are OSX 10.8.* with 64bit CPU (would different CPU matter)?

as for -O0 - wouldn't that be like super slow?

[nagachika (Tomoyuki Chikanaga)]

Thank you for provide the binary. I can reproduce with it.

It seems that rb_rational_new2(ZERO, ONE) in read_num() return a Fixnum 0 because canonicalization == 1.

I've found that it can be reproduced in trunk with mathn/rational.

$ ruby-trunk -r rational/math -e 'p ".8".to_r'
0

mathn/complex and mathn/rational are extension libraries and statically linked with your binary. But mathn.rb doesn't load automatically because it is a pure-ruby library.
Add require "mathn" fixes this problem in short.

$ ./bin/ruby -rmathn -e 'p ".8".to_r'
(4/5)

I have no idea why the problem is revealed only when the binary is transferred to other system.
nobu, how do you think?

[nagachika (Tomoyuki Chikanaga)]

• Status changed from Feedback to Open

[zzak (Zachary Scott)]

• Category set to platform/darwin
• Assignee set to nobu (Nobuyoshi Nakada)

[nagachika (Tomoyuki Chikanaga)]

• Status changed from Open to Closed

r43514 (in trunk) maybe fix this issue. Please check it.

[mpapis (Michal Papis)]

just checked and r43514 does not fix the issue, what other information can I provide to help fix that?

[nagachika (Tomoyuki Chikanaga)]

• Status changed from Closed to Open

[mpapis (Michal Papis)]

the latest binary with patches from r43449 and r43514 is available here http://rvm.io/binaries/experimental/osx_106plus_ruby_8879/ruby-2.0.0-p247.tar.bz2
all used patches:

https://github.com/wayneeseguin/rvm/blob/master/patches/ruby/2.0.0/43449.patch
https://github.com/wayneeseguin/rvm/blob/master/patches/ruby/2.0.0/43514.patch
https://github.com/wayneeseguin/rvm/blob/master/patches/ruby/2.0.0/cc_env.patch
https://github.com/wayneeseguin/rvm/blob/master/patches/ruby/2.0.0/static.patch
https://github.com/wayneeseguin/rvm/blob/master/patches/ruby/2.0.0/remove_digest_so.patch
https://github.com/wayneeseguin/rvm/blob/master/patches/ruby/2.0.0/logging.patch

[nagachika (Tomoyuki Chikanaga)]

Hi, thank you for your cooperation.

Hmm, it seems that 43514.patch is not applied to the given binary (from http://rvm.io/binaries/experimental/osx_106plus_ruby_8879/ruby-2.0.0-p247.tar.bz2).
43514.patch delete init_ext_call() from load.c but backtrace information from lldb with the given binary report that Init_rational() is called from init_ext_call().

(lldb) bt

• thread #1: tid = 0x53a46f, 0x0000000100247c70 rubyInit_rational, queue = 'com.apple.main-thread, stop reason = breakpoint 1.1 frame #0: 0x0000000100247c70 rubyInit_rational frame #1: 0x00000001002e6b78 rubyinit_ext_call + 24 frame #2: 0x00000001003febf6 rubyrb_vm_call_cfunc + 390 frame #3: 0x00000001002e6b15 rubyruby_init_ext + 69 frame #4: 0x000000010012934e rubyInit_ext + 574 frame #5: 0x00000001003907c0 rubyrequire_libraries + 80 frame #6: 0x000000010038eb22 rubyruby_process_options + 2338 frame #7: 0x00000001002e23c3 rubyruby_options + 163 frame #8: 0x00000001001290f7 rubymain + 71 frame #9: 0x0000000100000d74 ruby`start + 52

Please confirm the patch was really applied.

[mpapis (Michal Papis)]

it works! the patch was broken, updated binary is available here (OSX 10.6+) http://rvm.io/binaries/osx/10.9/x86_64/ruby-2.0.0-p247.tar.bz2

[nagachika (Tomoyuki Chikanaga)]

• Tracker changed from Bug to Backport
• Project changed from Ruby master to Backport200
• Category deleted (platform/darwin)
• Status changed from Open to Assigned
• Assignee changed from nobu (Nobuyoshi Nakada) to nagachika (Tomoyuki Chikanaga)

Thank you for your investigation.
I'll try to backport for it.

[nagachika (Tomoyuki Chikanaga)]

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

This issue was solved with changeset r43656.
Michal, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

---

merge revision(s) 43449,43514,43525: [Backport #8879] [Backport #8883]

* load.c (ruby_init_ext): share feature names between frame name and
  provided features.

* load.c (rb_feature_p): deal with default loadable suffixes.

* load.c (load_lock): initialize statically linked extensions.

* load.c (search_required, rb_require_safe): deal with statically
  linked extensions.

* load.c (ruby_init_ext): defer initalization of statically linked
  extensions until required actually.  [Bug #8883]

* load.c (ruby_init_ext): defer initialization of statically linked