I'm finding a way pausing program execution by code on Xcode
As an example, I can stop execution with abort() C function. This pops Xcode debugger up.
However, this exits program completely, so I'm finding a way to pause execution. So I can resume execution after checking execution states.
This is required for handling light-weight errors. I tried pause() C function, but it doesn't work. The execution aborted instead of pausing.
If you want to be able to break on a specific function whenever there's an error, then define a function like so:
void BREAK_HERE_Eonil(void) {
NSLog(#"Set a breakpoint on BREAK_HERE_Eonil to debug.\n");
}
Call BREAK_HERE_Eonil() whenever you would like to enter the debugger. Set a breakpoint on BREAK_HERE_Eonil() in Xcode. Now, run under the debugger. Whenever you hit this function, you'll break into the debugger.
You might also be able to use the old Debugger() call; Xcode has an option under the Run menu to "Stop on Debugger()/DebugStr()".
You can also just run your app under the debugger and hit the big pause button in the debugger window whenever you want to break in.
Another method I often use in iOS programming is to include a breakpoint in an if statement. Like so:
if (your_condition) {
//put an Xcode breakpoint here
}
That way I can conditionally call breakpoints in loops and other places that get called too often to have an unconditional breakpoint.
Related
So I am using Qt Creator with LLDB as debugger.
To debug stuff I add breakpoints and when the code hits the breakpoint it stops and I can see the back trace and all and that's useful. However, sometimes I don't want to stop and I am only interested in whether the breakpoint is hit, or I want to inspect a value there.
I usually do this with adding debugging messages but that generally takes a lot of time to recompile the project and rerun the scenario.
I'm wondering is there a better way to do this, using a debugger, preferably LLDB.
All the break set commands take a --auto-continue option (one-letter: -G) that will instruct lldb to continue after stopping for the breakpoint (and running any of its commands).
You can run lldb commands when a breakpoint is hit (e.g. to do a backtrace or print some locals) using the break command add command or by adding any number of -C options to the break set command. You can also add a Python implemented callback to the breakpoint as described here:
https://lldb.llvm.org/use/python-reference.html#running-a-python-script-when-a-breakpoint-gets-hit
if you need to do something fancier to gather your report when you hit the breakpoint.
If you want to edit currently active break point you can do the following:
breakpoint modify <break_point_id> -G true
Currently i'm on a project which has some main loop which is quite slow. Putting a breakpoint into it implicates i have to press F9 each time, and there are a lot of iterations. What i imagine is to see the program 'move' on one of my screens, without wondering if it is stuck or not.
I already have log outputs and so on, my question really focuses on this 'show debug without stop' feature.
What i imagine is to see in this main loop the current line highlighted as i it was a line-by-line execution, but without breakpoints and without going down in the subcalls.
Does any of you know a way to do something like this or wish the same thing ?
Thanks !
Your Debug tool window has a "Mute breakpoints" control:
If you leave it ON, your application won't stop at breakpoints. You can switch it off later once you reach the point where you actually want to start debugging (e.g. mute breakpoints while the app is doing all the initial loading tasks, while you navigate to the screen you want to debug etc. and then unmute them).
I'm not quite sure this is it but , how about disabling focus on breakpoint:
Put your cursor on the line you'd like to breakpoint and hit ctrl-shift-f8 (on a pc). You can choose not to suspend when a breakpoint is hit, and/or you can add logging that the breakpoint was triggered. If you need to, you can add a condition that must be met before the breakpoint is triggered.
Here's what this looks like for me:
I'm trying to debug a Terminal app upon launch, so I've created a new scheme and selected:
I build my app, then I go to Terminal and run the app. Immediately, instead of hitting a breakpoint, I get:
And in my terminal the app is run and exited normally, without debugger attached:
My breakpoint is valid as I hit it when I launch automatically from Xcode.
Cleaned build folder, restarted Xcode etc, no avail. My code is simple as I've just created a default project:
int main(int argc, const char * argv[]) {
#autoreleasepool {
// insert code here...
}
printf("aha");
return 0;
}
In my project settings, I've set a custom location for my executable for debugging to be deterministic (I don't want Xcode to append random strings into the build data in derived data folder):
Why am I getting this error? How can I debug my executable upon launching from terminal?
Are you showing the app code just as an example or is that what you are really trying to attach to? The attach wait works by sampling the process list till it sees a process of that name, then attaches to it. So depending on how far the process has run before lldb manages to attach to it, it may very well have executed the code you set the breakpoint on before it attached. Especially if not much goes on before the breakpoint.
The best way to arrange to attach to something that you need to run in terminal is to put a spin in the program, like:
int keep_spinning = 1
while (keep_spinning)
{
sleep(1);
}
the when you attach, you can set keep_spinning to 0 and continue.
I had this problem with a (command line) unit test implemented with Google gtest, using Xcode 10. My session used "attach automatically", but I had the same problem, consistently. I had a breakpoint set near the beginning of a test case (the only one), and it never stopped, and I got the same message. Even stranger, I got it when I removed all breakpoints and simply tried to run through the program using the debugger. I was however able to get the breakpoint I wanted by setting another breakpoint early in the test's main() function. That can be tricky with gtest, because it's possible to use a generic main that simply launches all tests. Fortunately for me, we roll our own shared main. I put a breakpoint before the call that runs all the tests linked with our main, and it stopped politely as ordered. Then when hit the "continue" button, it stopped at the original break that I wanted. I have no idea why this would work when other things did not, but if anyone else is having a problem like the above, I recommend putting a breakpoint as early in the program as possible and check to see if it gets you out of this particular bind. If you happen to be in EXACTLY the same situation I encountered (that is, you are using a gtest unit test), note that no matter how early in the test instance itself I tried to break, I got the same failure mode. For me, it had to be in main. Best of luck.
Is there a way to invoke the script debugger programmatically?
I want to create a dialog box that offers an option to start the debugger (as if it had reached a breakpoint in one of the callers), similar to the one that QTP offers when it encounters a playback error.
This is for QTP, but i estimate that if one can do this for VBS, it'll work there too.
Updated update
The stop statement does what I want -- except for this (in conjunction with QTP/UFT):
it stops where the stop statement is (and not in the caller's code) (I think I could work around that by putting the function with the stop statement into a file that I load in a way that it won't be jumped into by the debugger (LoadLibrary? ExecuteFile?));
it requires me to have triggered one "real" breakpoint during the run session previously, and continued execution with "Run"/F5.
Does Err.Raise work for what you're trying to achieve?
I am trying to launch an application via the ShellExecute() API call. This application contains only a main function which does some processing and exits.
Now I have put DebugBreak() in starting of main. When ShellExecute() is called the application is launched successfully but it does not ask for breaking.
How can I debug my application when launched from other application using ShellExecute()?
I am using VC++ .
If DebugBreak() isn't workign for you, try _CrtDbgBreak(). Note that _CrtDbgBreak only works in a debug build.
_CrtDebugBreak definitely works for me to make a launched process break on startup, although I'm pretty sure DebugBreak does also.
Note that both functions will make it look like the process has crashed, since they raise an exception. That is normal and gives you the opportunity to attach a debugger via the crash dialog. (The crash dialog also lets you terminate the process; don't use that, obviously.)
Also note that if you have a catch-all SEH exception handler around your main then the exception raise by DebugBreak & friends will be swallowed up and the app will simply exit without showing the crash dialog or letting you attach to it.
You can't do this with VC++; with WinDbg this is just .childdbg 1 to debug all child processes. With VC++, you can use Image File Execution Options in a pinch - check out http://codereflect.com/2009/09/20/how-to-debug-child-process-using-windbgvisual-studio/ for more info. Really though, if you've got the time to learn WinDbg, it's much better at this.
you can try this, it's ok in xp system.
app.exe is your application name,
-s1...-s3 is command line arguments.
HINSTANCE hRet = ShellExecute(NULL, L"open", L"vsjitdebugger.exe", L" app.exe -s1 a1 -s2 a2 a3 -s3", szExePath, SW_SHOW);
There is now a Microsoft Child Process Debugging Power Tool.
The method I use for things like this is to embed some interactive code, which you can either delete afterwards, comment out or conditionally enable. In a few cases we have this code enabled by querying an environment variable which is set by the tool that launches the main application. This allows me to click a check box, hit launch and have the breakpoint dialog in seconds.
if (MessageBox(NULL,
_T("Attach the debugger now, then choose Yes to hit a breakpoint"),
_T("Attach Debugger"),
MB_YESNO) == IDYES)
__debugbreak();
This gives you the ability to attach the debugger when the dialog box appears and the option to hit a breakpoint or not. My earlier versions didn't give me the option and after a while I realised some of the time I wanted the breakpoint, and some of the time I didn't.