Ruby

It is confusing, but I think there is nothing wrong. There are two points.

The first point is that the location for a method written in C is represented by its caller's location.
This is an example: Integer#times is implemented in C, so its location is represented as t.rb:2.

1: def foo 2: 1.times do 3: raise 4: end 5: end 6: 7: foo 

$ ./miniruby t.rb t.rb:3:in `block in foo': unhandled exception from t.rb:2:in `times' # <== See this line from t.rb:2:in `foo' from t.rb:7:in `<main>' 

Note that there is no t.rb:1 location in the backtrace. A backtrace location represents where the interpreter is executing, so usually, the first line of a method body tend not to be included in a backtrace (unless an exception occurs during evaluation of optional arguments, for example).

The second point is that a rescue clause for a method body is considered as if the clause is called from the first line of the method body. This is exceptional, and may be confusing; it reflects the implementation detail. But currently it is at least intentional, I think.
This is an example: t.rb:4 is virtually called from t.rb:1 which is the first line of the method body.

def foo raise rescue raise "foo", cause: nil end foo 

$ ./miniruby t.rb t.rb:4:in `rescue in foo': foo (RuntimeError) from t.rb:1:in `foo' # <== See this line from t.rb:7:in `<main>' 

So, now your example can be understood as:

# exc.backtrace -e:1:in `<main>' /builddir/t/evaluator.rb:22:in `eval' # This line is for `Binding#eval`; the method is written in C, so it shows its caller's location /builddir/t/evaluator.rb:22:in `eval' # This line is for `WebConsole::Evaluator#eval`; the interpreter now executes Line 22, so it is correct -e:1:in `<main>' # caller /builddir/t/evaluator.rb:24:in `rescue in eval' /builddir/t/evaluator.rb:21:in `eval' # This is included for the exception of a method rescue clause -e:1:in `<main>'