Backport #8879
closedString#to_r fails after moving ruby to other OSX system
Description
=begin
I got reported by users (((<rvm issue 2189|URL:https://github.com/wayneeseguin/rvm/issues/2189>))) 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
Updated by nagachika (Tomoyuki Chikanaga) almost 9 years ago
- 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.
Updated by mpapis (Michal Papis) almost 9 years ago
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?
Updated by nagachika (Tomoyuki Chikanaga) almost 9 years ago
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?
Updated by nagachika (Tomoyuki Chikanaga) almost 9 years ago
- Status changed from Feedback to Open
Updated by zzak (Zachary Scott) over 8 years ago
- Category set to platform/darwin
- Assignee set to nobu (Nobuyoshi Nakada)
Updated by nagachika (Tomoyuki Chikanaga) over 8 years ago
- Status changed from Open to Closed
r43514 (in trunk) maybe fix this issue. Please check it.
Updated by mpapis (Michal Papis) over 8 years ago
just checked and r43514 does not fix the issue, what other information can I provide to help fix that?
Updated by nagachika (Tomoyuki Chikanaga) over 8 years ago
- Status changed from Closed to Open
Updated by mpapis (Michal Papis) over 8 years ago
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
Updated by nagachika (Tomoyuki Chikanaga) over 8 years ago
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 ruby
Init_rational, queue = 'com.apple.main-thread, stop reason = breakpoint 1.1 frame #0: 0x0000000100247c70 ruby
Init_rational
frame #1: 0x00000001002e6b78 rubyinit_ext_call + 24 frame #2: 0x00000001003febf6 ruby
rb_vm_call_cfunc + 390
frame #3: 0x00000001002e6b15 rubyruby_init_ext + 69 frame #4: 0x000000010012934e ruby
Init_ext + 574
frame #5: 0x00000001003907c0 rubyrequire_libraries + 80 frame #6: 0x000000010038eb22 ruby
ruby_process_options + 2338
frame #7: 0x00000001002e23c3 rubyruby_options + 163 frame #8: 0x00000001001290f7 ruby
main + 71
frame #9: 0x0000000100000d74 ruby`start + 52
Please confirm the patch was really applied.
Updated by mpapis (Michal Papis) over 8 years ago
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
Updated by nagachika (Tomoyuki Chikanaga) over 8 years ago
- 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.
Updated by nagachika (Tomoyuki Chikanaga) over 8 years ago
- 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