In ruby-debug, the next command takes you to the next line of code to be executed, regardless of whether that line is in your own code, or in the rails framework, or in a gem.
Is there some way to force ruby-debug (1.9) to jump to the next line that it encounters in your code without stopping at all the other lines it must execute along the way?
Yes, there is.
You can use break linenum to manually set a breakpoint on an arbitrary line number (for instance the next one), and then type c to continue to the next breakpoint.
The documentation for ruby-debug breakpoints would probably help you a bit as well.
Related
One feature I really appreciate in PyCharm is the evaluate expression window, where I can evaluate an expression and a block of code at breakpoint. I am wondering whether there is an equivalent / similar feature in Xcode for IOS development.
I have tried the following which does not give me what I need:
using "print" command in the debug console
using PO command to print object in debug console.
inserted "expression" in debug console.
Insert break point before and after the block of code which I want to evaluate
What I really need if possible is:
To be able to evaluate a block of code (after which, the value of the variables will be updated in the "variable watch window".
Change the expression / block of code to be evaluated at run time.
Once at break point, evaluate a block of code after the break point multiple times, without running the code before the break point again (this is the issue with inserting two breakpoints before and after the block of code, because I need to re-run the code before the first break point if I want to change my expression / block of code)
I use Xcode7 to debug a App.
Seems step into behave like the step over, can't jump into the execution of a sub procedure? It's just jump to the next line in the source code each time.
And if I'm debug in the UIKit method(I don't have source code), it's jump to the next instruction.
As you have found, step-in avoids frames with no debug information. Most people like to just hit one step command, rather than switching between step & next depending on the line they are on, and in my experience, tend to choose step. This is made more pleasant if the debugger doesn't stop in printf & other code you have no debug info for.
However, lldb's "step" command has an option to control this:
-a <boolean> ( --step-in-avoids-no-debug <boolean> )
A boolean value that sets whether stepping into functions will step over functions with no debug information.
If you use this frequently, you can either reset the step alias to include this option, or make another alias that includes it. Use the command alias command to do this.
And if you always want step-in to step into code with no debug information, just set the global setting:
settings set target.process.thread.step-in-avoid-nodebug 0
either at the start of a debug session or in your .lldbinit.
Note, most of lldb's commands are documented in the help system. For instance, help step would have shown the above option for the step command, and apropos step would have shown the setting.
From GDB Manual:
Also, the step command only enters a function if there is line number information for the function. Otherwise it acts like the next command. This avoids problems when using cc -gl on MIPS machines. Previously, step entered subroutines if there was any debugging information about the routine.
And I found Step into works well when I have source file.
So maybe I have make a mistake. But the lldb is very lack of documents.
I have a very big code, and I need to debug it fully, so I need to set breakpoint on every line of the code. Ho to do this?
No need to set breakpoints, F7 is the shortcut for "Debugger step into" which will do exactly what you're trying to do, step through the program stopping at every line.
If you want to skip certain method calls, F8 ("Debugger step over") can also be helpful.
This is a long standing source of frustration, but maybe there is something I'm missing. If i'm in the middle of debugging, and I want to exit the debugger and return to IRB or Rails Console, "quit" won't work as it will exit IRB. "finish" also seems to have the same effect as continue. Using "delete" to remove breakpoints and then trying "continue" or "finish" doesn't work.
Any ideas?
At least in byebug, you can do this:
eval return
Which has the net effect of evaluating a return statement from the current function. That works sometimes, depending on how the call stack looks.
Now while this doesn't remove the current breakpoint .... if you just want control back, this will do that in most cases, depending on how your code is structured.
It also is useful to do this when creating a debug entry in your code:
byebug unless $continue
So if all else fails in a debugging session, you can always run
$continue = true
c
Now this opens up a whole set of possibilities.
This SO question has a few good suggestions. It deals with specifically with debugging inside of loops. One great solution is to set the break point outside the loop, then from irb set it inside the loop and clear it manually when you want to.
Basically it comes down to putting a little bit of thought into where you set your breakpoints.
Other than that there doesn't appear to be anything else you can do.
If I run a program and an exception is raised I am asked if I want to continue or break.
If I choose break I can see where the exception is coming from but if the break is in a library or system file not one of my source files (Say the exception is in System.pas or Controls.pas) I need to manually step the execution forward using F8 until it returns to one of my files, so I can see what part of my code caused the exception.
This can take a long time.
I know I should be catching lower level exceptions in my code but in this instance it's not hitting one of my exception handlers.
Is there a way to say
run forward with execution until you get to file X or
until you get back into a project specific file.
I'm also interested out of general curiosity on how other compilers / IDEs handle this.
Apologies if I haven't made this as clear as a I should.
You can resolve this by using the Stack View window.
Open the Stack View window (CTRL+ALT+S).
Double click on the method in the stack view where you wish to insert a breakpoint.
The unit, containing the caller method opens and the cursor is positioned on the caller method.
Set your breakpoint.
There's an even simpler way than Lieven's suggestion. Follow the first 3 steps as he laid them out, but don't place a breakpoint.
The problem with placing a breakpoint is that you have to clear it afterwards or you'll end up getting dropped into the debugger every time you pass that line. If you only want to run to a certain line and then drop to the debugger once, put the cursor on that line (the insertion point, not the mouse cursor) and press F4 (Run to Cursor). It's like a one-time breakpoint.
There are several ways:
Use the "Next source line" function (Shift+F7)
Use the call stack and double-click on the function you need, add a breakpoint there and hit "Run" (F9).
Use the "Step out" (Shift+F8) function until you are back into your own code.