I put breakpoint. I used command ⌥⌘-click on breakpoint.
It showed me following options.
How can I use these options.
1. AppleScript
2. Capture GPU Frame
3. Debugger Command
4. Log Message
5. Shell Command
6. Sound
There are other options
1. Condition
2. Ignore
3. Action
4. Options
What are these options. How are they working?
You can read this detailed tutorial on breakpoints options: https://www.bignerdranch.com/blog/xcode-breakpoint-wizardry/
Short summary:
Condition: if condition evaluated to true, breakpoint is triggered.
Ignore is self explaining. Like "ignore first 2 passes".
Action: what to do if breakpoint is triggered.
Options: set if you do not want to stop on this breakpoint in XCode
For action field you can choose what to do when breakpoint is triggered. Possible values is:
AppleScript: execute entered AppleScript code
Capture GPU frame: capture OpenGL frame contents
Debugger Command: execute entered GDB command
Log Message: log entered message to console
Shell Command: execute entered shell command
Sound: play a sound file
These options may be used to perform additional actions once the debugger hits this breakpoint.
The "Log Message", for example, can be very useful as it lets you print automatically collected data like the hit count for this breakpoint, the name of the method it's in, values of variables and other expressions.
Using the same principal, you can have the debugger run an Apple script, execute shell commands, etc.
You can also check the "Automatically continue after evaluating actions" so the debugger won't actually break while hitting it - but the action will still be executed.
There are even more advanced options you can utilize like performing the action only when a certain condition is met, ignore the breakpoint unless it has a certain minimum of hits, and even chaining several operations (+ and - buttons).
Related
I've hit an assertion in code and wondering if there's a way to create a wrapper around the assert that would enable breaking out and continuing execution or some other function that would enable a way to suppress the assert through the lldb debugger.
assert(condition(), makeCriticalEvent().event.description, file: fileID, line: UInt(line))
This is the standard assertion in apples libraries here. When I hit this assertion I tried continuing execution but it stays stuck at the assertion. I'd like to silence the assertion (likely through the lldb debugger by typing some command). Anyone have an idea how to do this?
You have to do two things. First, you have to tell lldb to suppress the SIGABRT signal that the assert delivers. Do this by running:
(lldb) process handle SIGABRT -p 0
in lldb. Normally SIGABRT is not maskable, so I was a little surprised this worked. Maybe because this is a SIGABRT the process sends itself? I don't think there's any guarantee suppressing SIGABRT's has to work in the debugger so YMMV, but it seems to currently. Anyway, do this when you've hit the assert.
Then you need to forcibly unwind the assert part of the stack. You can do that using thread return, which returns to the thread above the currently selected one w/o executing the code in that frame or any of the others below it. So just select the frame that caused the assert, go down one frame on the stacks and do thread return.
Now when you continue you won't hit the abort and you'll be back in your code.
XCode 7.2.1
iPad Retina iOS 9.2 Simulator
I have several breakpoints set in a particular class in an XCode project.
Everything I discuss below takes place in this one class file.
I set the breakpoints on -(int16_t)areaNbr by clicking in the gutter, and set no conditions or anything on them. I confirmed they existed as far as LLDB is concerned by running breakpoint list from the LLDB prompt.
The project scheme is set to build for debugging, not release.
I run the project in the simulator, and stop at a breakpoint in a different method than the one in question, at which time I want to go to the LLDB prompt and call po [self areaNbr] and step through areaNbr.
Please note, as this may be quite relevant, I have NO code in the project itself that calls
-(int16_t)areaNbr
Now, I CAN get this to stop at my breakpoints on -(int16_t)areaNbr if I add some code to the project that calls the method.
For example, if I add something like NSLog(#"... %d", [self areaNbr])
I know the issue has nothing to do with compiling away the method simply because nothing calls it, because if that were true, then my call to po [self areaNbr] wouldn't be spitting out the result to the debugger window as pictured below. So the method is being compiled, and certainly recognized as existing by the debugger for execution purposes... just not for stepping purposes.
FYI, [self area] is returning "Area01"
Calling breakpoint list in LLDB returns the following
By default, lldb does not stop at breakpoints in hand-called code. The majority of folks use expr & expr -O -- i.e. po to print values & objects and were annoyed if they stopped at breakpoints they had set for other purposes.
However, it is easy to control this behavior, just use:
(lldb) expr -i 0 -- [self areaNbr]
Then you will stop at your breakpoint.
In this example, I left out the -O which is the object printing part, since if you just want to call this method, you likely don't care about calling description on the result after the expression is evaluated.
You can see all the options for expression evaluation by doing:
(lldb) help expr
Update: I've updated the text below to reflect results of my further investigations.
I want to debug my Windows CE 6 service from Visual C++ 2008. But breakpoints in several service API functions don't get hit, while should be. And that's not all. Seems like setting a breakpoint sometimes changes the code flow.
I have breakpoints set on all the service's exported functions (xxx_Init, xxx_Open, xxx_IOControl, etc.). I deploy the service DLL debug binary to a device and then I attach the debugger to the servicesd.exe process on the device.
After I run
services load MYSVC
on the device console, the module gets loaded, all the breakpoints become enabled and then the breakpoint in the xxx_Init function gets hit. I then execute and exit the function by pressing F5 in VC++. So far, so good.
But then, I run the
services start xxx:
command. Under the hood it calls the CreateFile API which results in a call to my xxx_Open function. If the CreateFile succeeds, then the DeviceIoControl API is called, which in turn calls my xxx_IOControl.
My implementation of xxx_Open just logs and returns a non-zero value, allowing the upper CreateFile API call to succeed:
DWORD APIENTRY xxx_Open(DWORD data, DWORD access, DWORD shareMode)
{
APP_LOG_INFO() << L"The service is being opened";
return 1; // Breakpoint here
}
If there is a breakpoint set on the "return 1" line, the breakpoint does not get hit, but I've got the
xxx: is not a valid service
response on the console, as if the function returned 0. If I remove the breakpoint, then everything goes fine.
The same goes if I set a breakpoint on the code in xxx_IOControl function:
DWORD xxx_IOControl(DWORD code, /* ... */)
{
DWORD error = ERROR_SUCCESS; // (1)
switch (code) // (2)
{
...
default: // (3)
...
}
Having a breakpoint on the line (1) leaves the error variable unitialized. Having a breakpoint on the line (2) makes the code to fall to the default branch on line (3), even if there exists a case branch for the code provided. In any of these cases the breakpoints are not hit.
At the same time, if I LoadLibrary my DLL (from a test executable), GetProcAddress of the xxx_Open and xxx_IOControl and call them, the debugger works as intended, all the breakpoints get hit and the code flow seem to be correct.
What am I missing? Why the debugger interfere with the services in such a weird way? Is there a way to reliably debug the service functions (I need IOControl mostly)?
Say have a few blocks of code in my project with this pattern:
dispatch_semaphore_wait(mySemaphore);
// Arbitrary code here that I could get stuck on and not signal
dispatch_semaphore_signal(mySemaphore);
And let's say I pause in my debugger to find that I'm stuck on:
dispatch_semaphore_wait(mySemaphore);
How can I easily see where the semaphore was last consumed? As in, where can I see dispatch_semaphore_wait(mySemaphore); was called and got through to the next line of code? The trivial way would be to use NSLog's, but is there a fancier/faster way to do this in the debugger with Xcode 4?
You can print debugDescription of the semaphore object in the debugger (e.g. via po), which will give you the current and original value (i.e. value at creation) of the semaphore.
As long as current value < 0, dispatch_semaphore_wait will wait for somebody else to dispatch_semaphore_signal to increment the value.
There is currently no automatic built-in way to trace calls to dispatch_semaphore_signal/dispatch_semaphore_wait over time, but that is a useful feature request to file at bugreport.apple.com
One way to trace this yourself would be by creating symbolic breakpoints on those functions in Xcode, adding a 'Debugger Command' breakpoint action that executes bt and setting the flag to "Automatically continue after evaluating" the breakpoint.
Another option would be to use DTrace pid probes to trace those functions with an action that calls ustack().
Suppose I use QTPs recovery scenario manager to set the playback synchronization timeout to 0. The handler would return with "continue with next statement".
I'd do that to make sure that any following playback statements don't waste their time waiting for the next non-existing/non-matching step before failing:
I have a lot of GUI tests that kind of get stuck because let's say if 10 controls are missing, their (consecutive) playback steps produce 10 timeout waits before failing. If the playback timeout is 30 seconds, I loose 10x30 seconds=5 minutes execution time while it really would be sufficient to wait for 30 seconds ONCE (because the app does not change anymore -- we waited a full timeout period already).
Now if I have 100 test cases (=action iterations), this possibly happens 100 times, wasting 500 minutes of my test exec time window.
That's why I come up with the idea of a recovery scenario function setting the timeout to 0 after/upon the first failed playback step. This would accelerate the speed while skipping the rightly-FAILED step, yet would not compromise the precision/reliability of identifying the next matching GUI context (which creates a PASSED step).
Then of course upon the next passed playback step, I would want to restore the original timeout value. How could I do that? This is my question.
One cannot define a recovery scenario function that is called for PASSED steps.
I am currently thinking about setting a method function for Reporter.ReportEvent, and "sniffing" for PASSED log entries there. I'd install that method function in the scenario recovery function which sets timeout to 0. Then, when the "sniffer" function senses a ReportEvent call with PASSED status during one of the following playback steps, I'd reset everything (i.e. restore the original timeout, and uninstall the method function). (I am 99% sure, however, that .Click and .Set methods do not call ReportEvent to write their result status...so this option might probably not work.)
Better ideas? This really bugs me.
It sounds to me like you tests aren't designed correctly, if you fail to find an object why do you continue?
One possible (non recovery scenario) solution would be to use RegisterUserFunc to override the methods you are using in order to do an obj.Exist(0) before running the required method.
Function MyClick(obj)
If obj.Exist(1) Then
obj.Click
Else
Reporter.ReportEvent micFail, "Click failed, no object", "Object does not exist"
End If
End Function
RegisterUserFunc "Link", "Click", "MyClick"
RegisterUserFunc "WebButton", "Click", "MyClick"
''# etc
If you have many controls of which some may be missing and you know that after 10 seconds you mentioned (when the first timeout occurs), nothing more will show up, then you can use the exists method with a timeout parameter.
Something like this:
timeout = 10
For Each control in controls
If control.exists(timeout) Then
do something with the control
Else
timeout = 0
End If
Next
Now only the first timeout will be 10 seconds. Each and every subsequent timeout in your collection of controls will have the timeout set to 0 which will save your time.