In Xcode, say you write an app for the iphone and it has a runtime
error in it. What I've been seeing is that it just closes out the
program in the simulator but doesn't really hilight or give me any
feedback as to what line caused the crash... am I missing something??
Note: I don't consider the console to be very effective since
it just spits out an error, but I still need to find where in
the heck that bug is stemming from in the code.
In the console, above the stack trace, it should say something like "[ClassName selectorName] unrecognized selector sent to instance".
Make sure you really meant to send that selector to that class. If you post what it is, we might be able to help more.
To access GDB, enable breakpoints, add one to your code by clicking in the line number gutter, press build and debug and finally open the debugger (CMD+Shift+Y).
Look in the console (command-shift-R).
You can set a global breakpoint on exceptions, which will let you trace the exact point at which they occurred. To do so, select the Run | Show | Breakpoints menu item in Xcode to bring up the breakpoints dialog. Select Global Breakpoints (so that this will be enabled for all of your projects) and create a breakpoint on objc_exception_throw in libobjc.A.dylib.
Now if you start your application by choosing Run | Debug - Breakpoints On, or manually enable breakpoints in the debugger window (Run | Debugger) before running, the application should halt at the point where the exception is thrown. You can then look at the stack trace in the debugger window, where it will highlight the particular line that caused the exception.
Related
I have 4 breakpoints but only 2 are getting hit. What I notice is that the breakpoints getting get hit show a small check mark in the breakpoints view.
What does this check mark mean and how can I activate my other breakpoints?
There is some explanation of the various symbols here:
What different breakpoint icons mean in Eclipse?
I've just tried it myself and it appears that your breakpoints are not disabled, but the little check mark only appears once you're actually executing the function that the breakpoint is in. So the reason your breakpoints aren't hit, is because there is no code path that leads into the code you're trying to debug, i.e. you're not calling it.
Found it. This is an issue where breakpoints other than on the main thread are not hit. This is an exclusive problem on the Samsung Galaxy S5 under Lollipop.
http://developer.samsung.com/forum/thread/android-studio-does-not-stop-on-some-breakpoints-when-connected-to-samsung-galaxy-s5-with-lollipop-5/202/277622?boardName=General&listLines=15&startId=zzzzz~
I'm running my application on the simulator but as soon as it starts it just closes I guess it crashes, however I dont get any error message or reason why it's crashing, I'm running it as debug also, is there anyplace or anyway to get an error message?
Try switching to "debugger" view, and look at the console from gdb, if it crashes you will see the error, and hopefuly the call stack.
Example of crash message: EXC_BAD_ACCESS.
If you don't have the call stack visible, you can try to type 'bt' (for back trace) at the gdb prompt.
A lot of times when my application randomly crashes before launching, there is a problem in an interface builder file (such as a connection to a now non-existant object). Check your interface builder files to see any potential bad connections or errors and if you can't find any, put an NSLog in your applicationDidFinishLaunching method to see if the application is actually being started before it crashes.
In Xcode, choose Run menu, then choose Debug — Breakpoints On. Xcode should now point you to the location in code where your app crashes in the Debugger view.
I just discovered (thanks to another very helpful post) that I can use GDB commands to create breakpoints that log information to the GDB console, whether debugging on the device or simulator. This is like NSLog, but much nicer in that you don't have to wait for the console to catch up, you don't have annoying timestamps, and you can turn them on/off at run time via the XCode breakpoint view).
Very nice, and I invested time figuring out how best to log messages and variables together. (Use the GDB command po [NSString stringWithFormat: #"Your message: %d %#",variable,[[object expression] description]]) for maximum versatility.
Everything worked wonderfully in the simulator. When I finally got around to device debugging, I was getting the messages just fine, but GDB was STOPPING on every breakpoint despite the fact that I configured them to auto-continue by checking the box in the breakpoint view.
I tried adding a "continue" commmand to each breakpoint, and it worked but GDB also started spewing information about every breakpoint hit and telling me "Continuing" after every line.
My questions:
Does this happen for you?
Can I change something so that auto-continue also works on the device
Can I tell GDB to be less verbose and only give me the output I print?
Please help!!
David
I've run into the same behavior. It turned out that XCode had duplicated the breakpoint at the intended line. Perhaps there's a bug where a left click occasionally adds a hidden breakpoint rather than disabling?
The solution was this:
Select the "Breakpoint Navigator" tab of the Navigator frame on the left
Look for duplicate breakpoints either manually or by entering the class name in the search box at the bottom of the Navigator. (remember that multiple project sections of the list may both contain a breakpoint for the same class)
Right-click on one and select Edit to figure out if it's the continue or not.
Right-click on the unwanted breakpoint and delete
David,
There are some useful console commands that you might want to familiarize yourself with.
info b (lists all breakpoints)
ena (enables all breakpoints)
dis (disables all breakpoints)
ena X (enable breakpoint number X)
dis X (disable breakpoint number X)
GDB also supports conditional breakpoints:
cond X [condition]
And, commands to execute automatically when a breakpoint is hit:
command X
Aaron
Another very useful option is a watchpoint - break only when given expression changes.
When I bring up console after my iPhone app crashes, it often says "unrecognized selector sent to instance 0x blah blah blah." How can I find out what variable this is? Is there a way in the debugger? Is it even possible? Thanks.
In gdb you could type
po 0x12345678
to print the -description of the object at that address. But this info is seldom useful. You should instead check the backtrace of the exception first, which can locate the line of code that causes the problem.
It's very helpful to create an Exception breakpoint, and with Xcode 7.3, it's never been easier. This will help you find the line of code causing an exception.
add breakpoint on the line where the app crashes
click the breakpoint in the Project Navigator menu
find the breakpoint you just created and select it
click the "+" at the bottom left
Select "Add Exception Breakpoint"
Run your code...whenever you get a "unrecognized selector sent to instance 0x blah blah blah," the debugger will stop on the line that's causing the problem.
I'm learning iPhone programming from Erica Sadun's The iPhone Developer's Cookbook. When I run the app I created by following the steps in the Temperature Conversion Example starting on page 81 in the simulator, it terminates due to an uncaught exception. (See http://groups.google.com/group/iphonesdk/browse_frm/thread/6f44a90fdb8da28a?hl=en for the question I posted to the iPhoneSDK Google Group.)
The exception is thrown after calling UIApplicationMain() from my main(). If I look through the stack trace in the debugger, all I see is (of course) assembly. How do I find out what kind of exception was thrown?
Update:
Learning the details of the exception from the Debugger Console was enough to help me solve the problem. (See http://groups.google.com/group/iphonesdk/browse_frm/thread/6f44a90fdb8da28a?hl=en.) I verified that I could set a symbolic breakpoint on objc_exception_throw, but I didn't look to see if the backtrace from there would have been helpful.
Put a breakpoint at objc_exception_throw and run your app via Debug instead of Run
To clarify, what you're actually seeing when you get an exception without the breakpoint is the same stack trace always - it's the uncaught exception handler. The type of exception is logged to the Run console, but if you want to see a backtrace for where the exception was raised, that's what the breakpoint is for.
In the new Xcode (at least starting from v4.5), you can catch all exceptions easily by doing this:
Bring up breakpoint navigator (⌘6)
Click + on the bottom left
Add Exception Breakpoint
I think the above is the same as a breakpoint on objc_exception_throw. http://samwize.com/2012/09/26/xcode-4-dot-5-tips-and-tricks/
http://ijoshsmith.com/2011/11/28/debugging-exceptions-in-xcode-4-2/
Same as samewize's solution, but also shows how to make this breakpoint show up by default in all your projects (right click on breakpoint, Move Breakpoint To, User).
As Kevin answered, you will find more helpful debugging info by setting a breakpoint at objc_exception_throw.
If you are using Xcode 4.2, you can add this symbolic breakpoint by going to Breakpoint Navigator > Click on the add icon on the bottom left > Add symbolic breakpoint > Enter objc_exception_throw for Symbol > Done.