3

I'm trying to use pry and pry-byebug to step through the execution of some code in a Rails console. I started the console with

pry -r ./config/environment

I then set a breakpoint:

break Foo#bar

Then make a new Foo and call bar on it:

Foo.new.bar

I expected step into Foo#bar, but instead the method just executed normally.

Is there some way to get this workflow to work?

Kevin Griffin
  • 14,084
  • 7
  • 28
  • 23
  • Have you tried using the line number based approach to this? From the documentation: `break app/models/user.rb:15` This seems much more explicit. – jaydel Aug 16 '16 at 13:58
  • Also, can you clarify if you have a requirement that you be able to do this from within the pry-byebug session or if you could just setup a breakpoint in the code itself as suggested by @kcdragon in his answer. If the latter, please accept his answer. – jaydel Aug 16 '16 at 14:04

3 Answers3

6

I found the answer: the debugger is not re-entrant. So you need to do this:

[1] pry(main)> binding.pry
[1] pry(main)> break Foo#bar
Breakpoint 1: Foo#bar (Enabled) :

6: def bar
7: end

[2] pry(main)> c # continue and exit the debugger we started on the first line
=> nil
[3] pry(main)> Foo.new.bar
Breakpoint 1. First hit.
Kevin Griffin
  • 14,084
  • 7
  • 28
  • 23
  • This is great! NB: In the _rails console_, call `binding.pry`, then call `break ...` to set breakpoints, then use `exit` or an end-of-file character (`^D`) to exit to the initial rails console REPL (which might also be pry). Then from the rails console, run the code that you want to debug. – JellicleCat Dec 20 '21 at 18:03
1

Here is how I usually use pry-byebug

Add a call to binding.pry to the first line of the method Foo#bar

Run rails console

Call Foo.new.bar

You should see the pry REPL now

kcdragon
  • 1,724
  • 1
  • 14
  • 23
  • While this will work, the OP seems to be interested in dynamically adding breakpoints from inside a pry-byebug session. – jaydel Aug 16 '16 at 13:57
  • 1
    It seems like he is trying that approach but I don't know if that is because he knows about this approach and doesn't want to use it or he just needs any way to get it to work. – kcdragon Aug 16 '16 at 14:01
  • Definitely value in this answer--didn't mean to imply it was without merit. I was hoping that the OP would clarify if there's a requirement that he be able to do this dynamically. – jaydel Aug 16 '16 at 14:02
  • I do know about this approach, but often the above is useful to me when digging around in libraries I don't want to modify. :) – Kevin Griffin Aug 17 '16 at 07:10
1

Hmm, when I use pry-byebug to debug my code I use in the following way:

First require the pry-byebug gem in the beginning of the coding

require 'pry-byebug'

def main # Do some coding puts "Hello" binding.pry # break point here puts "World" end

main

Then when running it my terminal will return enter irb mode and return:

>     3: def main
>     4:   puts "Hello"
>     5:
>     6:   binding.pry
>  => 7:   puts "World!"
>     8: end
> 
> [1] pry(main)>

So the code indicates where I am right now, and from that point I could check every variable read before the breakpoint (on line 6). The breakpoint indicates the terminal have not yet read things after line 6, so if I had variables there, the terminal would not recognize them.

I could then type next, so binding.pry would jump to the next binding.pry point available or run through the whole code. Or I could simply type continue.

What is very important to remeber is to remove the require 'pry-byebug' and all the breakpoints lines before commiting your code, because we don't want the code to get stuck in those points, right? The user might not know how to deal with it :)

Hope it helped! First time trying to contribute to this awesome community :D

hassan_ss
  • 11
  • 2