How do you trace all the methods invoked across different files in a particular user flow ?
Putting breakpoints at different points and observing the backtrace does not seem like the most efficient way.
Instead I would like to -
1) Put a breakpoint across all methods in the interested project.
2) Make all the breakpoints run a debugger command which prints out the file name and method name.
3) Edit the breakpoints such that the program continues to execute after a breakpoint is hit. (This option is available when you edit a particular
breakpoint.) So we don't stop at any breakpoint.
4) Disable all the breakpoints until I reach the flow I need to work on.
5) Enable all the breakpoints right before starting the flow.
With this approach, we don't have to manually put breakpoints at different places to understand the execution flow. Once the flow is complete, I can just look at the debugger console and figure out the execution flow.
Now, the question -
How can we do this using lldb commands?
Would appreciate any input/suggestions.
You can't do this with the Xcode breakpoint interface, but in the lldb console you can do:
(lldb) break set -r . -s AppName
Breakpoint 1: 478 locations.
(lldb) br com add
Enter your debugger command(s). Type 'DONE' to end.
> bt
> continue
> DONE
(lldb)
That sets a "symbol name match regular expression breakpoint" on all names ("." matches everything) in the binary/shared library called AppName. If you leave off the -s option, it will match all symbols everywhere. That will work but quite slowly...
The command prints a backtrace and continues.
This makes just ONE breakpoint, so you can do:
(lldb) break disable 1
Till you need it, and then enable it with:
(lldb) break enable 1
If you only want to catch some methods, you can adjust the regular expression, and if you find you aren't interested in some of the places you are hitting, you can individually disable locations within the breakpoint you've made this way.
(lldb) break list 1
Will show you all the locations, and:
(lldb) break disable 1.2-1.10 1.15
etc. will disable the locations.
This might get a little slow, because your app will be starting & stopping all the time. But it will do what you are asking.
You can put breakpoints on all methods in different files, and to trace how execution happens within that method click on Stepover.
Step over - shortcut - f6, it stops execution at next loc.
Also alternatively you can check value of particular variable or array by typing "po VariableName" in output window.
you can add related methods name through adding the symbol exception breakpoints.
I am writing a small IDE with Single Steps using the Debugdemo.
Now I need an Event before and after a line is executed.
I would like to disable my Editor while the current Line is executed.
I found the OnLine Event but did not find out in what cases it is fired or how I can use it.
Any hints are welcome.
Greetings Klaus
The OnLine event is meant to alter the interpretation of code.
It is not meant for debugging purposes.
If you want to do that use the BreakPoints in TPSScriptDebugger.
Put a breakpoint on the line and after the line.
Now you will get a signal before and after the line is executed.
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.
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.
I often accidently step into code that I'm not interested in while debugging in Delphi.
Let's start by saying that I know that you can step over with F8, and that you can run to a certain line with f4.
Example:
function TMyClass.DoStuff():Integer;
begin
// do some stuff
bla();
end;
procedure TMyClass.Foo()
begin
if DoStuff()=0 then // press F7 when entering this line
beep;
end;
Example: I want to step into method DoStuff() by pressing F7, but instead of going there, I first end up in FastMM4.FastGetMem(), which is a massive blob of assembly code that obviously I'm not interested in at the moment.
There are several ways to go about this, and I don't like any of them:
Add a breakpoint on "bla" (almost useless if you only want to step into DoStuff on special occasions, like iteration 23498938);
Instead of pressing F7, manually move the cursor to "bla", and press F4 (Works for this simple example. In practice, it doesn't);
In case of FastMM: temporarily disable fastmm;
Is there any way to hint the IDE that I'm never interested into stepping into a certain block of code, or do I always have to set extra breakpoints or use F4 to try to avoid this?
I'm hoping for some magic compiler directive like {$NODEBUG BEGIN/END} or something like that.
In most cases being able to exclude entire units would be fine-grained enough for me, but being able to avoid certain methods or even lines of code would be even better.
Update: Maybe codegear should introduce something like skip-points (as opposed to break-points) :-)
There is a "magic nodebug switch". {$D-} will disable the generation of debug code. Place that at the top of your FastMM unit and you won't end up tracing into it. And if you do end up in a function you don't want to be in, SHIFT-F8 will get you out very quickly. (WARNING: Don't use SHIFT-F8 from inside an assembly-code routine that plays around with the stack. Unpredictable behavior can result. F4 to the bottom of it instead.)
If you're jumping into FastMM code, then there are memory operations occurring. The code you've shown doesn't have any memory operations, so your question is incomplete. I'll try to guess at what you meant.
When a subroutine has local variables of compiler-managed types (such as strings, interfaces, or dynamic arrays), the function prologue has non-trivial work to do. The prologue is also where reference counts of input parameters are adjusted. The debugger represents the prologue in the begin line of the function. If the current execution point is that line, and you "step into" it, you'll be taken to the RTL code for managing the special types. (I wouldn't expect FastMM to be involved there, either, but maybe things have changed from what I'm used to.) One easy thing to do in that situation is to "step over" the begin line instead of into it; use F8.
If you're really pressing F7 when entering your highlighted line, then you're doing it wrong. That's stepping into the begin line, not the line where DoStuff is called. So whether you get taken to the FastMM code has nothing to do with the implementation of DoStuff. To debug the call to DoStuff, the current execution point should already be the line with the call on it.
If you only want to debug DoStuff on iteration 23498938, then you can set a conditional breakpoint in that function. Click in the gutter to make a normal breakpoint, and then right-click it to display its properties. There you can define a condition that will be evaluated every time execution reaches that point. The debugger will only stop there when the condition is true. Press F8 to "step over" the DoStuff call, and if the condition is true, the debugger will stop there as though you'd pressed F7 instead.
You can toggle the "use debug DCUs" option to avoid stepping into most RTL and VCL units. I don't know whether FastMM is included in that set. The key difference is whether the DCUs you've linked to were compiled with debug information. The setting alters the library path to include or exclude the subdirectory where the debug DCUs are. I think you can configure the set of included or excluded debug directories so that a custom set of directories is added or removed based on the "debug DCUs" setting.
Back to breakpoints. You can set up breakpoint groups by assigning names to your breakpoints. You can use an advanced breakpoint to enable or disable a named group of breakpoints when you pass it. (Breakpoint groups can have just one breakpoint, if you want.) So, for example, if you only want to break at location X if you've also passed some other location Y in your program, you could set a disabled breakpoint at X and a non-breaking breakpoint at Y. Set the "enable groups" setting at Y to enable group X.
You can also take advantage of disabled breakpoints without automatic enabling and disabling. Your breakpoints appear in the "breakpoints" debugger window. If you're stepping through DoStuff and you decide you want to inspect bla this time, go to the breakpoint window and enable the breakpoint at bla. No need to navigate to bla's implementation to set the breakpoint there.
For more about advanced breakpoints, see Using Non-Breaking Breakpoints in Delphi, and article by Cary Jensen from a few years ago.
I may have missed something with your post, but with FastMM4 you can edit the FastMM4Options.Inc include file and remove the '.' from the following define:
From FastMM4Options.inc ****
{Enable this option to suppress the generation of debug info for the
FastMM4.pas unit. This will prevent the integrated debugger from stepping into
the memory manager code.}
{$.define NoDebugInfo}
When recompiling (might need building) the debugger will (should) no longer debug the FastMM code.
Use a precompiled non-debug DCU of FasmMM
In the project dpr file, I use
uses
{$IFNDEF DEBUG} FastMM4, {$ENDIF}
... // other units
to exclude FastMM4 during debug mode. Requires no change in FastMM4 so I don't have to remember to add {$D-} in FastMM when I change to a different version.
AFAIK, the debugger is only aware of the files in Browsing Path that you can modify in Options. So if you exclude the paths of modules you're not interested in debugging that will give the effect of what you want to do.
One caveat: code completion also relies on Browsing Path so you might run into occasions that code completion falls short when needed.
Although it isn't a direct answer to your question, you could modify your first suggested solution by putting breakpoint at bla that is only enabled when a breakpoint at Foo is passed (or some other condition of your choose, such as iteration count). Then it will only break when you want it to.
As an aside, I am finding more and more that I am not halting execution at break points, but rather dumping variable values or stack dumps to the message log. This allows more careful analysis than on-the-fly inspection of variables, etc. FWIW.
No. I don't believe there is a way to tell the debugger to never stop in a certain section of code. There is no magic directive.
The best you can do when you get into a routine you don't want to be in is to use Shift+F8 which will Run until the Return. Then do a F7 or F8 to exit the procedure.
Hmmm. Now I see Mason's answer. Learned something. Thanks, Mason. +1