I have looked around but I can't seem to find that information anywhere so I guess this is not possible
but I would like to be sure.
Is there a way to break out of a loop when using lldb ?
(And if not why has it not been implemented ?)
Debug information doesn't encode source constructs like loops, if branches, etc. That's been true of all the debug formats I've had to do with. So there's really no way that lldb could implement step out of loop - it has no way to know that loops are a thing.
The cleanest way to do this, when it's possible, is to set whatever condition the loop is checking to the "stop looping" value. Then set a breakpoint outside the loop and continue and the iteration you are in will be the last iteration.
You can also use the thread jump command to move the PC out of the loop, continuing from that point. Be very careful using this, however, as it's easy skip over some code you probably should have run. For instance if there were objects scoped to the loop, they won't get destroyed if you jump the PC to some line outside the loop.
If you know line, where loop ends, you can step out of loop with thread until <line>.
This is the same as setting temporary breakpoint in <line> but only one time.
Related
How do I a produce an infinite loop using a JFugue pattern. I tried the following
while loop
for loop with a high counter
In both cases, weird sounds get produced which are overlapped. When I run with a small counter like 10 in a for loop, it works fine.
I need a pattern to run infinitely until the player is stopped by calling player.close() by an user action (say from UI).
There's not a specific way to make a pattern run forever. This is partly because JFugue compiles music strings into MIDI code, so a pattern that ran forever would just be a infinitely-long MIDI file. Of course, if you use a specific number of times to repeat a pattern, the pattern could be too long or too short for your needs. The best option might be to look into JFugue's RealtimePlayer class, and create a separate thread that keeps playing sections of the metronome pattern while the thread is still active.
Let me know if that helps you get on the right path!
Can someone explain what is the purpose of the Step Over Thread and Step Into Thread debugger commands in Xcode? In what case is it useful to use them rather than the usual Step Over and Step Into? What is the difference and when does it matter?
Edit: To clarify the question, I'm not asking about the difference between Step Over/Step Into/Step Out, I'm asking about the difference between the normal and the "Thread" versions, and in what case one version is more useful than the other.
Step Into
Executes the current statement and then stops at the next statement. If the current statement is a function or script call, then the debugger steps into that function or script, otherwise it stops at the next statement.
Step Over
Executes the current statement and then stops at the next statement. If the current statement is a function or script call then the debugger executes the whole function or script, and it stops at the next statement after the function call.
Step Out
Steps out of the current function and up one level if the function is nested. If in the main body, the script is executed to the end, or to the next breakpoint. The skipped statements are executed, but not stepped through.
Argument is general About debugging so look at
What is the difference between Step Into and Step Over in the Eclipse debugger?
Looking at specific the focus is thread so you can look at your "multithread" application as single thread application without having multiple events/thread etc. running while you are stopped at break point. You have a "stable enviorment".
http://developer.apple.com/library/ios/#documentation/ToolsLanguages/Conceptual/Xcode4UserGuide/060-Debug_Your_App/debug_app.html
I just struggle with the same question. Question is a bit old but it looks like I found the proper answer.
Here in documentation, I found something like that:
Control-Shift to step into or over the active thread only while holding other threads stopped (the step icons show a dashed rather than solid line below the arrow).
Control-Shift-<Fx Key or click> are respective shortcuts for thread versions of step over and step into. So it looks like that this executes only current thread and suspending temporary all other threads. Normal versions continues execution of all not suspended threads.
a very simple explanation of this term:
Step Into, Step Over, Step Out Commands (Debug Menu)
According to this book:
Step Over Thread and Step Into Thread freeze all other threads while you advance the thread you're debugging. Hold down Shift and
Control while clicking the buttons, or select the commands in the
Debug menu, to get the effect.
I rarely used the netbeans debugger but I have this bug in my program which I'm trying to get to the bottom of. Basically my program searches a binary file (4.5gb) for a seqeunce of bytes and writes it to file. However, the programm always stalls at this specific point in the file when reading near halfway of the file (~2gb). They way I using the debugger if putting a breakpoint and keep "continuing" the debugger until it reaches that point in the file but it's going to take forever to reach the 2gb mark. I'm guessing there's a better way to use the debugger which I'm not aware of. Any suggestions?
Netbeans supports conditional breakpoints. If you add a breakpoint via the menu "Debug / New Breakpoint" (or just hit Ctrl+Shift+F8) you can specify a condition (either how often the breakpoint has to be hit until it execution is halted on this breakpoint or an expression).
You could keep a count of how much data you have processed, and add an if() block which checks whether you are up to the 2GB mark. Put a dummy command inside the if() block, and add a breakpoint on the dummy command; this will only be reached when you have processed sufficient data.
I may sound silly, but I am naive in debugging.
I have one doubt, in order to track the flow of execution in a program, what should be the optimum point to put a breakpoint?
Is it so that wherever we will put a breakpoint, the application execution flow before that would not be traced?
The best point to place a breakpoint is where you need the function to break.
If that exact point will not be reached because of conditionals, break on the conditional that would cause it to skip and ensure the code you do want to debug will get reached.
You need to place breakpoints where you can get to the code you wish to debug the fastest.
You would place a breakpoint very near or just before a piece of code you want to step through in order to debug it, then when execution pauses at your breakpoint, step through line by line to examine the state of variables and follow the path of execution.
i have found myself several times in the need of knowing the last values set to a range of variables that were in a certain portion of code, or method; maybe dispersed around the program.
does anyone know a way to select variables and know the last value set to them after the program ends running - in a windows maybe ?
There isn't anything I know of that will record every value ever assigned to every variable in your program in case you want to look at it later. It is possible with VS2010's historical debugging abilities to look at "values from the past" although I haven't used this yet, so I don't know if that ability extends "beyond death" of the process.
You may also be able to use tracepoints (VS2008 and later). These are like breakpoints, but instead of stopping execution they simply print information to the debug output. So you could add a tracepoint for a variable so that each time it is changed its value is reported (basically the same as printing the values out in your code, but you don't have to change your code to enable them, and can add them while your code is executing).
Two simple approaches that will work for pretty much any dev environment are:
Write the values to an application log each time they change, then read the last reported entries. If you realise you need 5 values from all around the program, simply printing them to the debug output will only take a few seconds to add to your program. (If you can't do this easily, then you're not encapsulating your data very well).
Put a breakpoint on the destructor of the class you're interested in, or at the start of the shutdown process just before you destroy the objects, or the last line of code in your program (for statics) (etc) and just use the debugger to drill down into the data.