Backport #8879

String#to_r fails after moving ruby to other OSX system

Added by Michal Papis 7 months ago. Updated 5 months ago.

[ruby-core:57074]
Status:Closed
Priority:Normal
Assignee:Tomoyuki Chikanaga

Description

=begin
I got reported by users ((())) that a static binary compiled for OSX after moving to other system fails for the method (({String#tor})):
ruby -e 'puts ".8".to
r'
0
The same binary checked on the build system produces proper result:
ruby -e 'puts ".8".tor'
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

Associated revisions

Revision 43656
Added by Tomoyuki Chikanaga 5 months ago

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

History

#1 Updated by Tomoyuki Chikanaga 7 months ago

  • Status changed from Open to Feedback

Hello,

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

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.

#2 Updated by Michal Papis 7 months 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?

#3 Updated by Tomoyuki Chikanaga 7 months ago

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

It seems that rbrationalnew2(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?

#4 Updated by Tomoyuki Chikanaga 7 months ago

  • Status changed from Feedback to Open

#5 Updated by Zachary Scott 6 months ago

  • Category set to platform/darwin
  • Assignee set to Nobuyoshi Nakada

#6 Updated by Tomoyuki Chikanaga 6 months ago

  • Status changed from Open to Closed

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

#7 Updated by Michal Papis 5 months ago

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

#8 Updated by Tomoyuki Chikanaga 5 months ago

  • Status changed from Closed to Open

#10 Updated by Tomoyuki Chikanaga 5 months 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 initextcall() from load.c but backtrace information from lldb with the given binary report that Initrational() is called from initext_call().

(lldb) bt
* thread #1: tid = 0x53a46f, 0x0000000100247c70 rubyInit_rational, queue = 'com.apple.main-thread, stop reason = breakpoint 1.1
frame #0: 0x0000000100247c70 ruby
Initrational
frame #1: 0x00000001002e6b78 rubyinit_ext_call + 24
frame #2: 0x00000001003febf6 ruby
rb
vmcallcfunc + 390
frame #3: 0x00000001002e6b15 rubyruby_init_ext + 69
frame #4: 0x000000010012934e ruby
Initext + 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.

#11 Updated by Michal Papis 5 months 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

#12 Updated by Tomoyuki Chikanaga 5 months ago

  • Tracker changed from Bug to Backport
  • Project changed from ruby-trunk to Backport200
  • Category deleted (platform/darwin)
  • Status changed from Open to Assigned
  • Assignee changed from Nobuyoshi Nakada to Tomoyuki Chikanaga

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

#13 Updated by Tomoyuki Chikanaga 5 months 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

Also available in: Atom PDF