rackup not working well with whereami #571

Closed
redgetan opened this Issue May 13, 2012 · 6 comments

Comments

Projects
None yet
4 participants
@redgetan
Member

redgetan commented May 13, 2012

I'm not sure if the bug is caused by rackup itself, but the behavior i'm seeing is that wherami shows the wrong lines of code when rackup is used (does not happen when i use thin directly, ie. thin -R chat.ru start).

To reproduce the problem:

1. Create file named chat.ru

require 'rubygems'
require 'pry'

class Hello

  def call(env)
    body = ["hello world!"]
    binding.pry
    [200, {}, body]
  end

end

use Rack::ContentLength
use Rack::ContentType, "text/plain"
run Hello.new

2. Run rack app

@reg ~/ruby/pry_sandbox [master]$ rackup chat.ru

Thin web server (v1.3.1 codename Triple Espresso)
Maximum connections set to 1024
Listening on 0.0.0.0:9292, CTRL+C to stop

3. Issue HTTP Request

Then, curl -i http://0.0.0.0:9292/

4. The output from pry would be:

From: /Users/reg/ruby/pry_sandbox/chat.ru @ line 7 Hello#call:

    7:     body = ["hello world!"]

5. When in fact it should have been:

From: chat.ru @ line 6 Hello#call:

     6:   def call(env)
     7:     body = ["hello world!"]
 =>  8:     binding.pry
     9:     [200, {}, body]
    10:   end

6. Some more observations from the pry console that might be useful

[1] pry(#<Hello>)> Hello.instance_method(:call).source_location
=> `["/Users/reg/ruby/pry_sandbox/chat.ru", 7]`

[2] pry(#<Hello>)> Pry::Method.from_binding(binding)
=> `#<Pry::Method:0x007fd24b935cb8
 @method=#<Method: Hello#call>,
 @source="body = [\"hello world!\"]\n",
 @visibility=nil>`
@YorickPeterse

This comment has been minimized.

Show comment Hide comment
@YorickPeterse

YorickPeterse May 18, 2012

Member

Could you re-format your issue a bit so that it makes a bit more sense? Right now it's hard to understand what the code examples are meant to tell.

Member

YorickPeterse commented May 18, 2012

Could you re-format your issue a bit so that it makes a bit more sense? Right now it's hard to understand what the code examples are meant to tell.

@redgetan

This comment has been minimized.

Show comment Hide comment
@redgetan

redgetan May 18, 2012

Member

just edited my explanation. hopefully its more clear now :)

Member

redgetan commented May 18, 2012

just edited my explanation. hopefully its more clear now :)

@YorickPeterse

This comment has been minimized.

Show comment Hide comment
@YorickPeterse

YorickPeterse May 19, 2012

Member

Just tested this and I can confirm that this indeed happens when using Pry and Rackup.

Output of gem env:

RubyGems Environment:
  - RUBYGEMS VERSION: 1.8.23
  - RUBY VERSION: 1.9.3 (2012-04-20 patchlevel 194) [x86_64-linux]
  - INSTALLATION DIRECTORY: /home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry
  - RUBY EXECUTABLE: /home/yorickpeterse/.rvm/rubies/ruby-1.9.3-p194/bin/ruby
  - EXECUTABLE DIRECTORY: /home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry
     - /home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@global
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - "install" => "--no-ri --no-rdoc"
     - "update" => "--no-ri --no-rdoc"
  - REMOTE SOURCES:
     - http://rubygems.org/

Output of rvm env:

export PATH ; PATH="/home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry/bin:/home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@global/bin:/home/yorickpeterse/.rvm/rubies/ruby-1.9.3-p194/bin:/home/yorickpeterse/.rvm/bin:$PATH"
export rvm_env_string ; rvm_env_string='ruby-1.9.3-p194@pry'
export rvm_path ; rvm_path='/home/yorickpeterse/.rvm'
export rvm_ruby_string ; rvm_ruby_string='ruby-1.9.3-p194'
export rvm_gemset_name ; rvm_gemset_name='pry'
export RUBY_VERSION ; RUBY_VERSION='ruby-1.9.3-p194'
export GEM_HOME ; GEM_HOME='/home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry'
export GEM_PATH ; GEM_PATH='/home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry:/home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@global'
export MY_RUBY_HOME ; MY_RUBY_HOME='/home/yorickpeterse/.rvm/rubies/ruby-1.9.3-p194'
export IRBRC ; IRBRC='/home/yorickpeterse/.rvm/rubies/ruby-1.9.3-p194/.irbrc'
unset MAGLEV_HOME
unset RBXOPT
Member

YorickPeterse commented May 19, 2012

Just tested this and I can confirm that this indeed happens when using Pry and Rackup.

Output of gem env:

RubyGems Environment:
  - RUBYGEMS VERSION: 1.8.23
  - RUBY VERSION: 1.9.3 (2012-04-20 patchlevel 194) [x86_64-linux]
  - INSTALLATION DIRECTORY: /home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry
  - RUBY EXECUTABLE: /home/yorickpeterse/.rvm/rubies/ruby-1.9.3-p194/bin/ruby
  - EXECUTABLE DIRECTORY: /home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-linux
  - GEM PATHS:
     - /home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry
     - /home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@global
  - GEM CONFIGURATION:
     - :update_sources => true
     - :verbose => true
     - :benchmark => false
     - :backtrace => false
     - :bulk_threshold => 1000
     - "install" => "--no-ri --no-rdoc"
     - "update" => "--no-ri --no-rdoc"
  - REMOTE SOURCES:
     - http://rubygems.org/

Output of rvm env:

export PATH ; PATH="/home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry/bin:/home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@global/bin:/home/yorickpeterse/.rvm/rubies/ruby-1.9.3-p194/bin:/home/yorickpeterse/.rvm/bin:$PATH"
export rvm_env_string ; rvm_env_string='ruby-1.9.3-p194@pry'
export rvm_path ; rvm_path='/home/yorickpeterse/.rvm'
export rvm_ruby_string ; rvm_ruby_string='ruby-1.9.3-p194'
export rvm_gemset_name ; rvm_gemset_name='pry'
export RUBY_VERSION ; RUBY_VERSION='ruby-1.9.3-p194'
export GEM_HOME ; GEM_HOME='/home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry'
export GEM_PATH ; GEM_PATH='/home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@pry:/home/yorickpeterse/.rvm/gems/ruby-1.9.3-p194@global'
export MY_RUBY_HOME ; MY_RUBY_HOME='/home/yorickpeterse/.rvm/rubies/ruby-1.9.3-p194'
export IRBRC ; IRBRC='/home/yorickpeterse/.rvm/rubies/ruby-1.9.3-p194/.irbrc'
unset MAGLEV_HOME
unset RBXOPT
@banister

This comment has been minimized.

Show comment Hide comment
@banister

banister May 30, 2012

Member

@redgetan the problem here is clearly the inaccurate source_location reported by rackup, ["/Users/reg/ruby/pry_sandbox/chat.ru", 7] It says the method definition starts at line 7, whereas it in fact starts on 6.

Any idea why this is? this seems like a bug in rackup, IMO. Or god knows what :)

Member

banister commented May 30, 2012

@redgetan the problem here is clearly the inaccurate source_location reported by rackup, ["/Users/reg/ruby/pry_sandbox/chat.ru", 7] It says the method definition starts at line 7, whereas it in fact starts on 6.

Any idea why this is? this seems like a bug in rackup, IMO. Or god knows what :)

@ConradIrwin

This comment has been minimized.

Show comment Hide comment
@ConradIrwin

ConradIrwin May 30, 2012

Member

This is caused by the way config.ru is run:

app = eval "Rack::Builder.new {\n" + cfgfile + "\n}.to_app"
          TOPLEVEL_BINDING, config

see https://github.com/rack/rack/blob/master/lib/rack/builder.rb#L40

Therefore the line number will be off-by-one...

One fix would be to set the line number to 0 in that eval (for MRI at least); another might be to make pry a bit less sensitive to having line numbers a bit inaccurate.

Member

ConradIrwin commented May 30, 2012

This is caused by the way config.ru is run:

app = eval "Rack::Builder.new {\n" + cfgfile + "\n}.to_app"
          TOPLEVEL_BINDING, config

see https://github.com/rack/rack/blob/master/lib/rack/builder.rb#L40

Therefore the line number will be off-by-one...

One fix would be to set the line number to 0 in that eval (for MRI at least); another might be to make pry a bit less sensitive to having line numbers a bit inaccurate.

@ConradIrwin

This comment has been minimized.

Show comment Hide comment
@ConradIrwin

ConradIrwin Jun 4, 2012

Member

Fix sent upstream: rack/rack#397.

We should try and keep track of issues like this and Issue #578 to see if we can spot patterns of brokenness to add heuristics for. But for now I'm inclined to say it's not really our problem.

Member

ConradIrwin commented Jun 4, 2012

Fix sent upstream: rack/rack#397.

We should try and keep track of issues like this and Issue #578 to see if we can spot patterns of brokenness to add heuristics for. But for now I'm inclined to say it's not really our problem.

@ConradIrwin ConradIrwin closed this Jun 4, 2012

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