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) about 11 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) about 11 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) about 11 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) about 11 years ago
- Status changed from Feedback to Open
Updated by zzak (zzak _) about 11 years ago
- Category set to platform/darwin
- Assignee set to nobu (Nobuyoshi Nakada)
Updated by nagachika (Tomoyuki Chikanaga) about 11 years ago
- Status changed from Open to Closed
r43514 (in trunk) maybe fix this issue. Please check it.
Updated by mpapis (Michal Papis) about 11 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) about 11 years ago
- Status changed from Closed to Open
Updated by mpapis (Michal Papis) about 11 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) about 11 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) about 11 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) about 11 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) about 11 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