my apps crash to this part of code
int main(int argc, char *argv[]) {
#autoreleasepool {
int retVal = UIApplicationMain(argc, argv, nil, nil);
return retVal;
}
}
So, where in xcode 4 i can see list of things that the program did before he goes to this point, In clear I want a know at what line the program crash in my code?
If you're seeing that then it's highly likely your program has terminated due to an uncaught exception. Take a look at this question to see how to set a breakpoint in objc_exception_throw which will then help as you'll be dropped right into the code that's causing the exception to be thrown.
Did you enable Zombies? To do it do the following:
1) Click on your app name(next to the Run and Stop buttons on top)
2) Click "Edit Scheme..."
3) In "Memory Management" put a tick on "Enable Zombie Objects"
Or you can get there by clicking "Product" --> "Edit Scheme..."
Hope it helps
Related
When i run my app, after a while it stops working and say thread 1: signal SIGABRT. it says it on this code:
#import <UIKit/UIKit.h>
int main(int argc, char *argv[])
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
It says it on this line:
int retVal = UIApplicationMain(argc, argv, nil, nil);
SIGABRT means an exception was triggered. The console log will print the exact exception message, and you need to look at that (post it here).
The problem is probably in your UIApplicationMain method
To Expand on user3109992 answer a SIGABRT usually means an exception was thrown. Generally you want to enable a global exception breakpoint so that your program will be stopped on the line of code that generated the exception rather than just crashing on main so that you can gain some meaningful information as to what happened.
To set a global breakpoint use the breakpoint navigator (looks like a diamond) on your left bar (or command 7). On the lower left click the + icon and choose "Exception Breakpoint". Now your program will crash at the point the exception is thrown. However this still won't print the actual exception to the console.
To print the exception to the console when the crash occurs select the stack frame that says something like "objc exception throw", it will be at the top of the left window. If your running on simulator type: po $eax and in general the exception will be printed to the console. Note that sometimes the register where the exception is located is different if your on a device or the 64 bit simulator so you can type: "register read" and it will give you a list of registers. The one at the top holds the exception so you can type: "po " to see it. You can have the exception print automatically when your program crashes at main by setting "Log Exceptions" in the scheme (product -> scheme-> edit scheme), accessed by choosing the diagnostic tab in the edit scheme window. However if you have a breakpoint set then your breakpoint will stop the program before the debugger gets a chance. I prefer the breakpoint approach because I usually want to poke around to understand more of whats going on when the app crashed.
I'd suggest you go back and watch some of the debugging and LLDB videos from the past couple of WWDC's as it sounds like you don't have a whole lot of experience with the debugger. The beginning videos have a ton of useful information.
I have a 5 tab expanded version of the TabController example supplied with Xcode 4.
I need to do some maths so have created an object to manage this.
The object is inserted just to the tab view that requires it.
It compiles fine.
HOWEVER when I click on a button to update the answer on screen it errors.
label.text = [[NSString alloc] initWithFormat:#"%.2f", c];
without the above line it doesn't.
The first line the debugger cites, in main.m, is:
return UIApplicationMain(argc, argv, nil, NSStringFromClass([SolarAppDelegate class]));
What am I doing wrong?
Please check the type of value you are having in c.
Also in new xcode you need to change some settings and add Exception break point if you want to know the exact error point.
If you have not added any exception break point then it will show you to this line only
I have downloaded a sample code of OpenEars form the web, in that at a place these statements were using:
#autoreleasepool {
…
}
which was giving error: Unexpected '#' in program, then I replaced these lines of code with:
NSAutoreleasePool *pool = [NSAutoreleasePool new];
…
[pool drain];
and now I am getting error: "clang failed with exit code 1 error".
Does any one know how to solve this?
I am using XCode 3.2.5
You definitely want to go back to #autoreleasepool{} but it sounds like the issue is in the compiler/arguments though. That may be difficult to debug, depending on how old the project was. Are you using the latest Xcode, and if so, can you "upgrade project settings"?
Suddenly when I try to run my app it immediately goes to the main.m file and shows me this SIGABRT error which I'm going to assume is Signal abort. I just can't figure out why that is happening. And I'm not sure what I am looking at in my debugging area. Please help!
#import <UIKit/UIKit.h>
#import "Mct2AppDelegate.h"
int main(int argc, char *argv[])
{
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([Mct2AppDelegate
class]));
}
}
Debugger Output:
Attaching to process 8004.
Pending breakpoint 1 - ""main.m":17" resolved
Couldn't register com.ebonybutler.Mct2 with the bootstrap server. Error: unknown error code.
This generally means that another instance of this process was already running or is hung in the debugger.Current language: auto; currently objective-c
Second Debugger Output since restart:
2012-02-29 16:46:45.561 Mct2[319:f803] * Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '-[UIViewController _loadViewFromNibNamed:bundle:] loaded the "Menu" nib but the view outlet was not set.'
* First throw call stack:
(0x13bb052 0x154cd0a 0x1363a78 0x13639e9 0xd7f0d 0xd83a9 0x2415e2 0xd85cb 0x25e4 0x13bcec9 0x155c2 0x1555a 0xbab76 0xbb03f 0xba2fe 0x3aa30 0x3ac56 0x21384 0x14aa9 0x12a5fa9 0x138f1c5 0x12f4022 0x12f290a 0x12f1db4 0x12f1ccb 0x12a4879 0x12a493e 0x12a9b 0x2032 0x1fa5)
terminate called throwing an exceptionCurrent language: auto; currently objective-c
Simple fix, if you're using iOS simulator, just close it down and rerun the project
This is Happens because your application getting terminate.
Try the following things in the below order:
Make sure all only one program is being debugged in XCode, close other running instances.
shut down your system and restart it before doing third steps.
Restart XCode, most of time this is take care of the issue.
If you are running this on the device and is still not working restart the device and try again.
It Really Work.
For assert macros in my iPhone project, I'm looking for a way to programmatically break into the debugger. On Windows (MSVC++), I can use __debugbreak() for this purpose. Invoking this function will stop my program, launch the debugger, and display a callstack of the line that called __debugbreak().
Is there anything similar to __debugbreak() for the iPhone? I've tried Debugger(), but that gives me a linker error.
Thanks,
Claus
edit
Turns out this also works:
#define Debugger() { raise( SIGINT ) ; }
I think it's the same principle.
I use this:
#define Debugger() { kill( getpid(), SIGINT ) ; }
I think it works
in the simulator and on the device.. no assembly required!
A helpful person on Apple's developer forum gave me the tip to use asm("trap") when running on the device and asm("int3") when running on the simulator. This makes the program break into the debugger if you started your programm in debug mode (Option-Command-Y).
(__builtin_trap() also breaks into the debugger, but you can't continue afterwards. assert(false) terminates the program with a message, but doesn't break into the debugger.)
First Add -DDEBUG to OTHER_CFLAGS on your debug target; this will define the DEBUG symbol when building a debug build.
Then add a simple assert macro to your prefix header:
#ifdef DEBUG
#define MyAssert(val) _MyAssert(val)
#else
#define MyAssert(val) do { } while(0)
#endif
Next create a _MyAssert function in a module somewhere:
#ifdef DEBUG
void _MyAssert(int expression)
{
if (expression == 0) {
NSLog(#"Assertion failed!"); // Place breakpoint here
}
}
#endif
Finally create a breakpoint on the NSLog line.
I just set a breakpoint at the place I want to stop. Xcode remembers breakpoints persistently, so any time I run the app with gdb, it'll stop at that point.
If you want to break on assertion failures, a good place to set a breakpoint is on the function objc_exception_throw, in the Objective-C runtime, which is what actually throws an exception. Use the Run > Show > Breakpoints window and double-click the "Double-click for symbol" row, then type the name.
Is there something wrong with the simple assert() macro? Something like
assert(pointerToTest != nil);
will halt your process at that point if the condition is not true. If running under the debugger, you'll be presented with a stack trace of calls that led to the failed assertion. If you want to trigger it every time you hit a certain code path, you could do
assert(false);
I find these assertions extremely useful for verifying that all IBOutlets are non-nil when a window or view is brought up from a NIB.
If you run your program in debug, your app should launch the debugger when it reaches an invalid assertion.
For it to stop, as Jens Alfke tried to say, you need to enable "Stop on Objective-C Exceptions" (under the Run menu).
For more info about debugging vs. releasing and asserts, read http://myok12.wordpress.com/2010/10/10/to-use-or-not-to-use-assertions/
While an ancient thread, found this while researching same topic for Xcode 7. What solved this for me was a feature called "Create Exception Breakpoint..."
Debug > Breakpoints > Create Exception Breakpoint...
This puts a special breakpoint in the Breakpoint Navigator (under View > Navigators > Show Breakpoint Navigator).
This breaks on the actual throw of the exception:
[ exception raise ]
without terminating your code execution. You can just continue if that is how your code is structured.
Double-clicking the break point marker next to "All Exception" lets you adjust where and how the exception break point stops:
Check out conditional breakpoints:
http://www.cocoabuilder.com/archive/message/xcode/2008/10/22/25358