where/bt does not in fact give a backtrace

[jrochkind]

'where' used to segfault for me, as in #1.

That's fixed in 1.1.2/1.13, it doesn't segfault anymore.

But it doesn't actually give a stacktrace, it only gives the first line of a stack trace. A stacktrace is awfully useful. The first line of one, not so much.

(rdb:1) where
--> #0 at line /home/rochkind/catalyst/lib/hip_pilot.rb:119
(rdb:1) help where
bt|backtrace            alias for where - display stack frames

Print the entire stack frame. Each frame is numbered, the most recent
frame is 0. frame number can be referred to in the "frame" command;
"up" and "down" add or subtract respectively to frame numbers shown.
The position of the current frame is marked with -->.

In ruby-debug of yore, where/bt would give me a complete backtrace, all the way up to root, same one that would be displayed from an exception that raised right there.

[cldwalker]

Please report OS and ruby version. I won't be able to look at this for awhile. Pull requests welcome in the meantime.

[jrochkind]

CentOS/RHEL 5.

ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

installed via rvm.

Is this special to me, others aren't having this issue?

[shailen]

+1

[cldwalker]

I've confirmed this is an issue in both 1.9s and was also an issue in ruby-debug19. Until I or someone else can get around to a proper fix, get your current stack with:

>>  pp caller.drop_while {|e| e[/ruby-debug|\(eval\)|debugger|\<internal:prelude\>/] }

[morganchristiansson]

+1

up/down is also broken as there are no frames to navigate to.

[deivid-rodriguez]

I'm not sure whether this is a bug or it is actually expected... I'll copy over an extract from the documentation which has helped me get more useful backtraces:

Something seems wrong here; TestTri.test_basic indicates that we are in class TestTri in method test_basic. However we don't see the call to this like we did in the last example when we used the where command. This is because the debugger really didn't spring into existence until after we already had entered that method, and Ruby doesn't keep call stack information around in a way that would give the information we show when running where.
If we want call stack information, we have to turn call-stack tracking on beforehand. This is done by adding Debugger.start.
Here's what our test program looks like so after we modify it to start tracking calls from the outset

#!/usr/bin/env ruby
require 'test/unit'
require 'tri2.rb'
require 'ruby-debug'
Debugger.start

class TestTri < Test::Unit::TestCase
  def test_basic
    debugger
    solutions = []
    0.upto(5) do |i|
      solutions << triangle(i)
    end
    assert_equal([0, 1, 3, 6, 10, 15], solutions, "Testing the first 5 triangle numbers")
  end
end

[siro-mateos]

+1

[siro-mateos]

Is there any walkaround to inspect the state of execution before catching a 'debugger' breakpoint? My problem is that I need to know what happened when an exception was raised, but 'up' command doen't work because there is no backtrace to climb...

[deivid-rodriguez]

Could you give a concrete example of your problem? Have you tried post-mortem debugging? Have you tried the workaround I posted here? What ruby version are you using? Thanks.