Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test & Verify Binary Releases #143

Closed
20 tasks done
danielpclark opened this issue Mar 5, 2018 · 21 comments
Closed
20 tasks done

Test & Verify Binary Releases #143

danielpclark opened this issue Mar 5, 2018 · 21 comments

Comments

@danielpclark
Copy link
Owner

danielpclark commented Mar 5, 2018

As of FasterPath v0.3.6 we now have binary releases compiled and deployed to Github. These need to be tested across many Ruby versions and operating systems to establish their reliability.

v0.3.7 Systems Tried

  • Mac & Ruby 2.3.4
  • Mac & Ruby 2.3.5
  • Mac & Ruby 2.3.6
  • Mac & Ruby 2.4.1
  • Mac & Ruby 2.4.2
  • Mac & Ruby 2.4.3

❌ Mac & Ruby 2.5.0

  • Linux & Ruby 2.3.4
  • Linux & Ruby 2.3.5
  • Linux & Ruby 2.3.6
  • Linux & Ruby 2.4.1
  • Linux & Ruby 2.4.2
  • Linux & Ruby 2.4.3
  • Linux & Ruby 2.5.0

These tests need to be conducted from a dependency stand point, not from downloading from this repository.

To test these you need to switch to a specific Ruby version, do a gem install, try it out in IRB and experiment with a few methods to see if it will segfault. Please try at least 3 methods a few different ways with string parameters. The gem install should retrieve the binary release and you won't need to compile the asset.

Some issues we may need to address:

  • In Pre-built binaries to remove the rustc dependency? #34 there was some discussion about minor Ruby versions not being compatible with each other and causing segfaults. This seems like a logical possibility since each compiled version of Ruby, even minor versions, creates a different library to be linked with.
  • The current file naming scheme has two parts I'd like to change. The first is that the semantic version for the build is grabbed from the Rust Carg.toml file instead of the Ruby gem version. I would like this to be versioned with Ruby. Looking at how Github Releases are organized this may not matter.
  • The second is that the Ruby version listed in the release packages is only Major and Minor versions and doesn't mark the patch level. If the first issue listed above is true this will need to change.

v0.3.9 Systems Tried

Since we know it worked on previous builds we really want to focus on Mac & Ruby 2.5.0.

  • Mac & Ruby 2.4.3
  • Mac & Ruby 2.5.0
  • Linux & Ruby 2.4.3
  • Linux & Ruby 2.5.0
@danielpclark
Copy link
Owner Author

danielpclark commented Mar 7, 2018

Okay, Linux works! 😄 🎉 I just need a Mac user to help now. Someone who doesn't have Rust installed.

Do the following:

gem install faster_path
irb
> require 'faster_path'
> FasterPath.join('a', 'b')

That should be enough per Ruby version.

@PikachuEXE
Copy link

PikachuEXE commented Mar 8, 2018

Seem failed on Mac with 2.5

MacOS 10.12.6
RVM master
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-darwin16]

2.5.0 :001 > require 'faster_path'
Traceback (most recent call last):
       10: from /users/pikachuexe/.rvm/rubies/ruby-2.5.0/bin/irb:11:in `<main>'
        9: from (irb):1
        8: from /users/pikachuexe/.rvm/rubies/ruby-2.5.0/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:39:in `require'
        7: from /users/pikachuexe/.rvm/rubies/ruby-2.5.0/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in `rescue in require'
        6: from /users/pikachuexe/.rvm/rubies/ruby-2.5.0/lib/ruby/site_ruby/2.5.0/rubygems/core_ext/kernel_require.rb:135:in `require'
        5: from /users/pikachuexe/.rvm/gems/ruby-2.5.0/gems/faster_path-0.3.7/lib/faster_path.rb:8:in `<top (required)>'
        4: from /users/pikachuexe/.rvm/gems/ruby-2.5.0/gems/faster_path-0.3.7/lib/faster_path.rb:17:in `<module:FasterPath>'
        3: from /users/pikachuexe/.rvm/rubies/ruby-2.5.0/lib/ruby/2.5.0/fiddle.rb:47:in `dlopen'
        2: from /users/pikachuexe/.rvm/rubies/ruby-2.5.0/lib/ruby/2.5.0/fiddle.rb:47:in `new'
        1: from /users/pikachuexe/.rvm/rubies/ruby-2.5.0/lib/ruby/2.5.0/fiddle.rb:47:in `initialize'
Fiddle::DLError (dlopen(/users/pikachuexe/.rvm/gems/ruby-2.5.0/gems/faster_path-0.3.7/lib/faster_path.so, 9): Library not loaded: /Users/travis/.rvm/rubies/ruby-2.5.0/lib/libruby.2.5.dylib
  Referenced from: /users/pikachuexe/.rvm/gems/ruby-2.5.0/gems/faster_path-0.3.7/lib/faster_path.so
  Reason: image not found)

But these versions got no issue:

  • ruby 2.4.3p205 (2017-12-14 revision 61247) [x86_64-darwin16]
  • ruby 2.3.6p384 (2017-12-14 revision 61254) [x86_64-darwin16]
  • 2.3.5
  • 2.3.4
  • 2.4.2
  • 2.4.1

Will edit and add results for other versions later (installing)

Edit 1: Update list of ruby versions with no issues

@danielpclark
Copy link
Owner Author

danielpclark commented Mar 8, 2018

Thanks! @PikachuEXE

Seem failed on Mac with 2.5

That could be a Thermite issue, or an environment variable changing the type of library extension. Only .so extensions have been built but the error you've shown tried to load a .dylib. Or it could even simply be a different requirement by the OS/Ruby setup.

For the Ruby 2.5 can you check this in irb? RbConfig::CONFIG['DLEXT']

I believe I can enforce both Linux & Mac to use the .so extension. That would take another samll monkey-patch. But that makes sense since TravisCI is only generating .so files for both Mac and Linux.

@PikachuEXE
Copy link

These versions:

  • 2.5.0
  • 2.4.3
  • 2.3.6
    All returns "bundle" for RbConfig::CONFIG['DLEXT']

@danielpclark
Copy link
Owner Author

danielpclark commented Mar 8, 2018

Thanks. It's odd that the problem only arose in 2.5. Thermite has a method to set all "bundle" as "dylib". lib/thermite/config.rb#L49-L59

@PikachuEXE
Copy link

I noticed it's trying to load
/Users/travis/.rvm/rubies/ruby-2.5.0/lib/libruby.2.5.dylib
not
/users/pikachuexe/.rvm/rubies/ruby-2.5.0/lib/libruby.2.5.dylib

Otherwise the file exists

@danielpclark
Copy link
Owner Author

danielpclark commented Mar 8, 2018

Ah. Thanks for the info. Would you feel comfortable sharing this info in an issue on Thermite?

@PikachuEXE
Copy link

Should I open a new issue on Thermite?
If not just copy it :P

@danielpclark
Copy link
Owner Author

Yeah I think he should know his Thermite gem sometimes tries to load a travis user on a Mac. You can reference this issue for him to look back to as well.

@PikachuEXE
Copy link

Issue created

@danielpclark
Copy link
Owner Author

Thank you! You've been a great help. 🎉

@PikachuEXE
Copy link

I reviewed the log for v0.3.7 build on Travis
It seems the only differences between different ruby versions in log are:

  • ruby version (of course)
  • bundler version (2.5 one use 1.16.1 while other use 1.16.1)
  • rubygems version (2.5 use 2.7.4 while other use 2.6.14)

Links to Travis build logs

I wonder what happens if bundler and rubygems are updated before build

@danielpclark
Copy link
Owner Author

@andrewstucki Looking at the research you've done on steveklabnik/ruby-sys#25 would applying your patch to my forks for both ruby-sys and ruru perhaps allow the Mac & Ruby 2.5.0 version to work on this issue?

I'm also curious as to whether this would allow me to not need to copy Ruby's lib to my Rust lib build directory. In ruru I put it in the .travis.yml file but for FasterPath I have two rake commands task :libruby_release and task :libruby_debug.

@andrewstucki
Copy link

@danielpclark So from the looks of the stack trace above it's just an issue of not being able to find libruby? If so, yeah, the patch should help you out since libruby shouldn't actually be needed at runtime (it's basically a fat library with like 90% of the Ruby internals in it that are already contained in the interpreter and dynamically used by extensions when they're loaded in memory).

Regarding the second question, yep, that should be the case, for the exact reasons above. Looking at how this library does appear to have some Rust tests that run outside of the context of the Ruby interpreter though, you'll need to do something like the re-export testing features that I added in steveklabnik/ruby-sys#31 and d-unsed/ruru#95 since Rust trying to execute the tests won't actually have access to the required symbols without linking in libruby.

In other words, run the Rust tests with that --features test flag, but build and ship without it and you should be good to go. Let me know if you decide to go ahead with that and if you run into any problems.

@danielpclark
Copy link
Owner Author

danielpclark commented Mar 14, 2018

The changes you've recommended @andrewstucki have been applied. The good news is I don't need --features test to make it work for either Ruby or Rust and now I don't need to copy the libruby file to the dependencies build directory anymore. So that's awesome!

If Mac & Ruby 2.5.0 doesn't work after this then the issue is Thermite specific for sure. I have a slight suspicion that the path to the lib being built may not be related to this fix. In which case Mac & Ruby 2.5.0 still won't work.

@andrewstucki
Copy link

@danielpclark awesome, so it sounds like the Rust tests don't actually use any of ruru and that all of that is tested through Ruby itself?

If that's the case just be careful with adding additional Rust tests that call down into ruby-sys itself. If you get any issues in the future because of unresolved rb_ symbols it'll probably be because of this and, in that case, just do the whole re-export --features test business!

@danielpclark
Copy link
Owner Author

danielpclark commented Mar 14, 2018

@danielpclark awesome, so it sounds like the Rust tests don't actually use any of ruru and that all of that is tested through Ruby itself?

That's not the case. This project specifically uses ruru for everything we depend on end product wise. It just works and I'm happy with that.

Just to clarify I did add the --features test to ruru like you did but did not need that on faster_path.

@danielpclark
Copy link
Owner Author

@PikachuEXE if you get a chance to try Ruby 2.5.0 again with this let me know how it goes. If it still doesn't work I'll close this off as an outside issue for Thermite. Thanks!

@PikachuEXE
Copy link

Now it works! (0.3.9)

Tried with 2.5.0, 2.4.3, 2.3.6

If there is anything else need to be tested let me know ;)

@PikachuEXE
Copy link

Fail when installing in a docker container

Env

root@557f37e012d6:/# ruby -v
ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux]
root@557f37e012d6:/# gem -v
2.7.6
root@557f37e012d6:/# bundle -v
Bundler version 1.16.1

Error Log

root@557f37e012d6:/# gem install faster_path
Fetching: minitar-0.6.1.gem (100%)
The `minitar` executable is no longer bundled with `minitar`. If you are
expecting this executable, make sure you also install `minitar-cli`.
Successfully installed minitar-0.6.1
Fetching: tomlrb-1.2.6.gem (100%)
Successfully installed tomlrb-1.2.6
Fetching: thermite-0.13.0.gem (100%)
Successfully installed thermite-0.13.0
Fetching: faster_path-0.3.9.gem (100%)
Building native extensions. This could take a while...
ERROR:  Error installing faster_path:
	ERROR: Failed to build gem native extension.

    current directory: /usr/local/lib/ruby/gems/2.5.0/gems/faster_path-0.3.9/ext
/usr/local/bin/ruby -rrubygems /usr/local/lib/ruby/gems/2.5.0/gems/rake-12.3.0/exe/rake RUBYARCHDIR=/usr/local/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0-static/faster_path-0.3.9 RUBYLIBDIR=/usr/local/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0-static/faster_path-0.3.9
checking for cargo... no
rake aborted!
****
Rust's Cargo is required to build this extension. Please install
Rust and put it in the PATH, or set the CARGO environment variable appropriately.
****

Tasks: TOP => default => thermite:build
(See full trace by running task with --trace)
Downloading compiled version (0.0.1) from GitHub

rake failed, exit code 1

Gem files will remain installed in /usr/local/lib/ruby/gems/2.5.0/gems/faster_path-0.3.9 for inspection.
Results logged to /usr/local/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0-static/faster_path-0.3.9/gem_make.out

/usr/local/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0-static/faster_path-0.3.9/gem_make.out:

current directory: /usr/local/lib/ruby/gems/2.5.0/gems/faster_path-0.3.9/ext
/usr/local/bin/ruby -rrubygems /usr/local/lib/ruby/gems/2.5.0/gems/rake-12.3.0/exe/rake RUBYARCHDIR=/usr/local/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0-static/faster_path-0.3.9 RUBYLIBDIR=/usr/local/lib/ruby/gems/2.5.0/extensions/x86_64-linux/2.5.0-static/faster_path-0.3.9
checking for cargo... no
rake aborted!
****
Rust's Cargo is required to build this extension. Please install
Rust and put it in the PATH, or set the CARGO environment variable appropriately.
****

Tasks: TOP => default => thermite:build
(See full trace by running task with --trace)
Downloading compiled version (0.0.1) from GitHub

rake failed, exit code 1

@danielpclark
Copy link
Owner Author

danielpclark commented Mar 15, 2018

Which docker container did this happen for you in? All of the Ruby docker images I tried worked. Specifically fro Ruby 2.5 it was ruby:2.5.0.

~ #: docker run -i -t ruby:2.5.0 /bin/bash
root@d2be2ff4eb3b:/# gem install faster_path
Fetching: minitar-0.6.1.gem (100%)
The `minitar` executable is no longer bundled with `minitar`. If you are
expecting this executable, make sure you also install `minitar-cli`.
Successfully installed minitar-0.6.1
Fetching: tomlrb-1.2.6.gem (100%)
Successfully installed tomlrb-1.2.6
Fetching: thermite-0.13.0.gem (100%)
Successfully installed thermite-0.13.0
Fetching: faster_path-0.3.9.gem (100%)
Building native extensions. This could take a while...
Successfully installed faster_path-0.3.9
4 gems installed
root@d2be2ff4eb3b:/# 

That could be an anomaly where the connection to Github Releases was unavailable. That's my best guess with the information we have here and now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants