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

Anyone meet segment fault 11 on mac when run padrino command #2097

Closed
grasp opened this Issue Nov 27, 2016 · 10 comments

Comments

Projects
None yet
4 participants
@grasp

grasp commented Nov 27, 2016

Do you want to request a feature or report a bug?

Bug

What is the current behavior?

Run any of padrino command , it will be segment fault 11.
Segmentation fault: 11

I have raised a issue to ruby.
https://bugs.ruby-lang.org/issues/12982

Which versions of Ruby, Padrino, Sinatra, Rack, OS are you using? Did this work in previous versions?

ruby 2.2, 2.3
padrino 0.13.3

@ujifgc ujifgc added the revalidate label Nov 27, 2016

@grasp

This comment has been minimized.

Show comment
Hide comment
@grasp

grasp Nov 28, 2016

1.using padrino 0.12.8 , same error .

  1. using RVM to install ruby 2.3.3,and it was same error .

3.using rbenv tried several ruby version , still same issue.

seems no workaround on mac....

but run other command like " thin start", it is quite well, only for padrino command.

grasp commented Nov 28, 2016

1.using padrino 0.12.8 , same error .

  1. using RVM to install ruby 2.3.3,and it was same error .

3.using rbenv tried several ruby version , still same issue.

seems no workaround on mac....

but run other command like " thin start", it is quite well, only for padrino command.

@adam12

This comment has been minimized.

Show comment
Hide comment
@adam12

adam12 Nov 28, 2016

Contributor

Can you generate a basic Padrino project? or does the Padrino gem segfault on something like padrino g project basic_project?

Contributor

adam12 commented Nov 28, 2016

Can you generate a basic Padrino project? or does the Padrino gem segfault on something like padrino g project basic_project?

@grasp

This comment has been minimized.

Show comment
Hide comment
@grasp

grasp Nov 28, 2016

Yes, Padrino can create a basic Padrino Project, after I reinstall 2.3.3 based on rbenv.

so It could be caused my specific project, Padrino works inside a new project.

maybe the problem is package a padrino project as a gem, I will try build again from scratch to see what happened.

grasp commented Nov 28, 2016

Yes, Padrino can create a basic Padrino Project, after I reinstall 2.3.3 based on rbenv.

so It could be caused my specific project, Padrino works inside a new project.

maybe the problem is package a padrino project as a gem, I will try build again from scratch to see what happened.

@ujifgc

This comment has been minimized.

Show comment
Hide comment
@ujifgc

ujifgc Nov 28, 2016

Member

Do Padrino 0.12.7 or 0.13.2 segfault?

Member

ujifgc commented Nov 28, 2016

Do Padrino 0.12.7 or 0.13.2 segfault?

@grasp

This comment has been minimized.

Show comment
Hide comment
@grasp

grasp Nov 28, 2016

it has same issue on above two build.

workaround:
after I comments line in Gemfile
#Distribute your app as a gem
#gemspec

and

lib/new_talk.rb
require 'padrino-core'

module NewTalk
extend Padrino::Module
#gem! "new_talk" # comments out here
end

it seems related with package as a Gem, but this may not be the root cause.

grasp commented Nov 28, 2016

it has same issue on above two build.

workaround:
after I comments line in Gemfile
#Distribute your app as a gem
#gemspec

and

lib/new_talk.rb
require 'padrino-core'

module NewTalk
extend Padrino::Module
#gem! "new_talk" # comments out here
end

it seems related with package as a Gem, but this may not be the root cause.

@skade

This comment has been minimized.

Show comment
Hide comment
@skade

skade Nov 28, 2016

Member

Can you put one of your failing projects on github somewhere?

Member

skade commented Nov 28, 2016

Can you put one of your failing projects on github somewhere?

@grasp

This comment has been minimized.

Show comment
Hide comment
@adam12

This comment has been minimized.

Show comment
Hide comment
@adam12

adam12 Dec 7, 2016

Contributor

@grasp

I'm able to temporarily fix the segfaults by changing the last line of your bin/padrino command to be:

load Gem.bin_path("padrino-core", "padrino")

What I believe is happening is that Bundler looks at the gemspec for your project, specifically the executables line, which is the list of files in bin/. It then writes out binstubs for each of those files, clobbering the proper binstubs with it's own broken version.

When Bundler generates a binstub with the line above, it normally puts the name of the Gem as it's first argument (padrino-core, haml, etc). In this instance it's mistakenly changing it to new_talk for all your binstubs.

When you run your padrino command, it loads the binstub, which incorrectly loads itself repeatedly.

You can solve this permanently by changing new_talk.gemspec's executable line to the following:

gem.executables   = ["new_talk"]

And re-running bundle --binstubs.

That said, your bin/new_talk binstub is still broken. It should look something like this:

#!/usr/bin/env ruby

Dir.chdir(File.dirname(__FILE__)+'/..')

# Start the app with Padrino::Server
require 'bundler/setup'
require 'padrino-core/cli/launcher'

ARGV.unshift('start') if ARGV.first.nil? || ARGV.first.start_with?('-')
Padrino::Cli::Launcher.start ARGV

# Start the app with Rack::Server
#require "rack"
#Rack::Server.start

Seems like some of the ideal advise is to move Gem specific bin's to the exe folder (bundler/bundler-features#105 and bundler/bundler@0ae330e).

Thoughts?

Contributor

adam12 commented Dec 7, 2016

@grasp

I'm able to temporarily fix the segfaults by changing the last line of your bin/padrino command to be:

load Gem.bin_path("padrino-core", "padrino")

What I believe is happening is that Bundler looks at the gemspec for your project, specifically the executables line, which is the list of files in bin/. It then writes out binstubs for each of those files, clobbering the proper binstubs with it's own broken version.

When Bundler generates a binstub with the line above, it normally puts the name of the Gem as it's first argument (padrino-core, haml, etc). In this instance it's mistakenly changing it to new_talk for all your binstubs.

When you run your padrino command, it loads the binstub, which incorrectly loads itself repeatedly.

You can solve this permanently by changing new_talk.gemspec's executable line to the following:

gem.executables   = ["new_talk"]

And re-running bundle --binstubs.

That said, your bin/new_talk binstub is still broken. It should look something like this:

#!/usr/bin/env ruby

Dir.chdir(File.dirname(__FILE__)+'/..')

# Start the app with Padrino::Server
require 'bundler/setup'
require 'padrino-core/cli/launcher'

ARGV.unshift('start') if ARGV.first.nil? || ARGV.first.start_with?('-')
Padrino::Cli::Launcher.start ARGV

# Start the app with Rack::Server
#require "rack"
#Rack::Server.start

Seems like some of the ideal advise is to move Gem specific bin's to the exe folder (bundler/bundler-features#105 and bundler/bundler@0ae330e).

Thoughts?

adam12 added a commit to adam12/padrino-framework that referenced this issue Dec 7, 2016

Switch to exe/ for application bins.
Using bin/ for our own executables is problematic when storing binstubs
in the same folder.

New acceptable practice per Bundler is to use the exe/ path for our own
bin.

Issue #2097
@adam12

This comment has been minimized.

Show comment
Hide comment
@adam12

adam12 Dec 7, 2016

Contributor

Seems like some of the ideal advise is to move Gem specific bin's to the exe folder (bundler/bundler-features#105 and bundler/bundler@0ae330e).

Thoughts?

I went ahead and opened a PR to make this change. Seems to be more benefits than downsides.

Contributor

adam12 commented Dec 7, 2016

Seems like some of the ideal advise is to move Gem specific bin's to the exe folder (bundler/bundler-features#105 and bundler/bundler@0ae330e).

Thoughts?

I went ahead and opened a PR to make this change. Seems to be more benefits than downsides.

adam12 added a commit to adam12/padrino-framework that referenced this issue Dec 7, 2016

Switch to exe/ for application bins.
Using bin/ for our own executables is problematic when storing binstubs
in the same folder.

New acceptable practice per Bundler is to use the exe/ path for our own
bin.

Issue #2097

ujifgc added a commit that referenced this issue Dec 7, 2016

Switch to exe/ for application bins. (#2099)
Using bin/ for our own executables is problematic when storing binstubs
in the same folder.

New acceptable practice per Bundler is to use the exe/ path for our own
bin.

Issue #2097
@grasp

This comment has been minimized.

Show comment
Hide comment
@grasp

grasp Dec 7, 2016

Yes, I verified the solution . it works.

Thanks for the fix.

@adam12

Many Thanks!

grasp commented Dec 7, 2016

Yes, I verified the solution . it works.

Thanks for the fix.

@adam12

Many Thanks!

@ujifgc ujifgc closed this Dec 25, 2016

@ujifgc ujifgc referenced this issue Mar 15, 2017

Closed

Release 0.14.0 #1971

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