Xcode 5.1.1 Thread 1: signal SIGABRT - iphone

Question

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);

Answer 1

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

Answer 2

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.