Project

General

Profile

This project is closed and read-only.

Actions

Backport #146

closed

Incorrect line numbers in "caller" output when evaluated in a Proc binding

Backport #146: Incorrect line numbers in "caller" output when evaluated in a Proc binding

Added by wilson (Wilson Bilkovich) over 18 years ago. Updated about 7 years ago.


Description

=begin
The second frame's line number appears to always be incorrect when a Proc is created via a non-toplevel method call.
This small program and its output illustrate the issue:

def first # line 1 of proc_caller.rb on my system
second
end

def second
b = third do
1 + 1
end
return b
end

def third(&b)
return b
end

eval("p caller(0)", first)

Output on recent 1.8 releases, including 1.8.6 and 1.8.7:
["proc_caller.rb:6:in second'", "proc_caller.rb:6:in first'", "proc_caller.rb:16"]

Output that I would expect: (line 6 is in 'second', not 'first')
["proc_caller.rb:6:in second'", "proc_caller.rb:2:in first'", "proc_caller.rb:16"]
=end

Updated by wilson (Wilson Bilkovich) about 18 years ago Actions #1

=begin
Everybody agrees that this is a bug, right?
=end

Updated by shyouhei (Shyouhei Urabe) over 17 years ago Actions #2

  • Assignee set to matz (Yukihiro Matsumoto)

=begin

=end

Updated by runpaint (Run Paint Run Run) about 17 years ago Actions #3

=begin
On 1.9 trunk:

 ["(eval):1:in `second'", "/tmp/proc_caller.rb:16:in `eval'", "/tmp/proc_caller.rb:16:in `<main>'"]

(I'm trying to understand the changes in caller output between 1.8 and 1.9 and failing).
=end

Updated by marcandre (Marc-Andre Lafortune) about 17 years ago Actions #4

  • Category set to core
  • ruby -v set to -

=begin
The expected output should be the same for
eval("p caller(0)", first.binding)
and
eval("p caller(0)", second.binding)
since the block has the same binding (i.e. that of second).

At the moment "p caller" is evaluated, both first and second have returned, so the output should not contain "proc_caller.rb:6". In neither case should we expect to see "proc_caller.rb:2:in `first'" in the backtrace.

It appears that when a block is captured (here by third), the binding is set the the full stack instead of just that of second. This leads to a longer backtrace, as seen with the output of caller or if an exception is raised in the eval.

Just to confirm that this bug is not present in Ruby 1.9; the output is quite sensible and the same from both first.binding and second.binding.
=end

Updated by shyouhei (Shyouhei Urabe) about 16 years ago Actions #5

  • Status changed from Open to Assigned

=begin

=end

Updated by jeremyevans0 (Jeremy Evans) about 7 years ago Actions #6

  • Tracker changed from Bug to Backport
  • Project changed from 2 to 5
  • Description updated (diff)
  • Status changed from Assigned to Closed
  • ruby -v deleted (-)
Actions

Also available in: PDF Atom