I've just began to learn iOS development and now I have a sigabrt on my main function. The error is triggered by calling:
int retVal = UIApplicationMain(argc, argv, nil, nil);
As I am very new to iOS programming I have no idea on what could by causing this error. One thing that I have found on my callstack is the following exception being raised: dyld_stub_objc_exception_throw
What could be causing this error?
I was having this problem in X-Code 4.2 and the issue was it couldn't find my Storyboard. The frustrating part was that there was no indication of what the actual exception was. I was able to get the exception in the log by adding a try / catch to my main function. (Note I'm using ARC, so if you aren't using ARC your main will look a little different with try catch)
int main(int argc, char *argv[])
{
int retVal = 0;
#autoreleasepool {
NSString *classString = NSStringFromClass([sortaAppDelegate class]);
#try {
retVal = UIApplicationMain(argc, argv, nil, classString);
}
#catch (NSException *exception) {
NSLog(#"Exception - %#",[exception description]);
exit(EXIT_FAILURE);
}
}
return retVal;
}
UIApplicationMain basically kicks off the rest of your application, so the actual cause of the crash could be anywhere in your application. You may need to look further down the call stack.
However, I note that you're passing nil as the final two parameters. The first nil is the principalClassName argument, which can legally be nil if you want UIApplication to be the principal class. The second nil is the application delegate name; you should pass nil if you load the delegate from the main nib. Do you? If you don't, that might be the problem (I can't say I've ever called this function with both of those arguments nil).
It was just a typical error of someone learning a new language/API. I forgot to properly set up the view.
UIView *controllersView = [myViewController view];
[window addSubview:controllersView];
Related
I'm running into a strange problem that I haven't run into before.
When you do cmd+U to run your Unit Tests (OCUnit for example) does it actually call the main.m, new up the appDelegate and run the app as if your had pressed cmd+R?
I only ask because I'm using CoreData behind this DataLayer. I'm mocking out the DataLayer successfully in my tests, but once I implemented a getAll method that is actually calling CoreData, the app/xcode is throwing an exception about the managed object model can't be nil. Which I understand, but I'm not meaning to actually new up the DataLayer class, and I've put a break point in my mainviewcontroller loadView method where it is calling the DataLayer getAll method. It shouldn't matter with tests because this is a mock object, but it's apparently calling the real instance.
So back to my question, when pressing cmd+U does it also run the app first then run the tests?
The application is actually run but there is a trick you can use to prevent it from running.
int main(int argc, char* argv[]) {
int returnValue;
#autoreleasepool {
BOOL inTests = (NSClassFromString(#"SenTestCase") != nil
|| NSClassFromString(#"XCTest") != nil);
if (inTests) {
//use a special empty delegate when we are inside the tests
returnValue = UIApplicationMain(argc, argv, nil, #"TestsAppDelegate");
}
else {
//use the normal delegate
returnValue = UIApplicationMain(argc, argv, nil, #"AppDelegate");
}
}
return returnValue;
}
Here's a variation of Sulthan's answer that uses XCTest, which is the default for test classes generated by XCode 5.
int main(int argc, char * argv[])
{
#autoreleasepool {
BOOL runningTests = NSClassFromString(#"XCTestCase") != nil;
if(!runningTests)
{
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
else
{
return UIApplicationMain(argc, argv, nil, #"TestAppDelegate");
}
}
}
This goes into main.m, which should be under Supporting Files in a standard project layout.
Then in your tests directory add:
TestAppDelegate.h
#import <Foundation/Foundation.h>
#interface TestAppDelegate : NSObject<UIApplicationDelegate>
#end
TestAppDelegate.m
#import "TestAppDelegate.h"
#implementation TestAppDelegate
#end
In Swift, I prefere to bypass a normal execution path inside application: didFinishLaunchingWithOptions:
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
guard normalExecutionPath() else {
window = nil
return false
}
// regular setup
return true
}
private func normalExecutionPath() -> Bool {
return NSClassFromString("XCTestCase") == nil
}
Code inside guard will remove any views created from storyboard.
If you're using Swift (you probably don't have a main.c), you have to do these steps :
1: remove #UIApplicationMain in AppDelegate.swift
2: Create an empty TestingAppDelegate.swift
import UIKit
class TestingAppDelegate: UIResponder, UIApplicationDelegate {
var window: UIWindow?
}
3: Create a file called main.swift :
import Foundation
import UIKit
let isRunningTests = NSClassFromString("XCTestCase") != nil
if isRunningTests {
UIApplicationMain(C_ARGC, C_ARGV, nil, NSStringFromClass(TestingAppDelegate))
} else {
UIApplicationMain(C_ARGC, C_ARGV, nil, NSStringFromClass(AppDelegate))
}
I found another solution to the problem:
int main(int argc, char * argv[])
{
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, ({
![NSProcessInfo processInfo].environment[#"XCTestConfigurationFilePath"] ?
#"AppDelegate" :
nil;
}));
}
}
From here: http://qualitycoding.org/app-delegate-for-tests/#comment-63984
Using xCode 7 and xCtool
xctool is capable of executing unit tests without running the app.
To get this working,
1 . Update target settings to run without a host app.
Select your project --> then test target --> Set the host application to none.
2. Install xctool , if you don't have it.
brew install xctool
3. Run the tests using terminal with xctool.
xctool -workspace yourWorkspace.xcworkspace -scheme yourScheme run-tests -sdk iphonesimulator
You can do that by setting the Host Application to None in your Tests Target.
Yes, your test target will have a target dependency to the app target, so the app target will be built when you press Cmd+U or Cmd+Shift+U.
Excellent answers above that suggest dynamically changing the application delegate at run time.
The small modification I make is to detect a unit test run by querying NSProcessInfo. The advantage is that you don't need to have a class that can be detected to see if unit tests are running.
int main(int argc, char * argv[])
{
// Put your App delegate class here.
const Class appDelegateClass = [ATAppDelegate class];
NSDictionary *const environmentDictionary =
[[NSProcessInfo processInfo] environment];
const BOOL runningUnitTests =
environmentDictionary[#"XCInjectBundleInto"] != nil;
NSString *delegateName =
runningUnitTests ? nil : NSStringFromClass(appDelegateClass);
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, delegateName);
}
}
The #"XCInjectBundleInto" property in environmentDictionary is the path to your unit tests bundle and is set up by Xcode.
I use the approach of Tomasz Bak plus some code of dwb answer and come up with the following:
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
BOOL runningTests = NSClassFromString(#"XCTestCase") != nil;
if (runningTests) {
self.window.rootViewController = [UIViewController new];
return true;
}
// Your normal code below this
....
}
Xcode Instruments is saying that I have a CGColor Leak.
Responsible Library: CoreGraphics
Responsible Frame: CGTypeCreateInstance
The stack is tracing it back to "Main" and the code below is highlighted as the error.
int main(int argc, char *argv[])
{
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([PDCAppDelegate class]));
}
}
Does anyone know how to fix this? Thank you all!
Likely, your PDCAppDelegate, or something it owns, is creating a CGColorRef and failing to release it.
Since I've installed the last xCode (my previous one was the 3.xx), a have hard times to debug my crashing apps. Indeed, the callstack is often empty. And the displayed method is
int main(int argc, char *argv[]) {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, #"MyAppDelegate");
[pool drain];
return retVal;
}
Ex :
Have anyone noticed this ? It was working perfectly on the same project with previous XCode. Is there any solution ?
Try setting Exception Breakpoint on Breakpoint panel:
Notice that you can change the number of items displayed in the stack frames view by dragging the slider at the bottom of the view.
I have a problem with debugging my xcode project.
When my app crashes i get an unreadable stacktrace like this:
2011-10-25 10:03:29.966 fruehstueck[2541:707] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSArrayM insertObject:atIndex:]: object cannot be nil'
*** First throw call stack:
(0x352918bf 0x303ce1e5 0x351e620f 0x2c381 0x46f6d 0x3138f7ff 0x3139bc39 0x3139baa9 0x3139b98f 0x3139b211 0x3139af53 0x3138f673 0x3138f349 0x3a347 0x3aa87 0x351eb435 0x3147473f 0x3137050f 0x3136ff01 0x313564ed 0x31355d2d 0x3717be13 0x35265553 0x352654f5 0x35264343 0x351e74dd 0x351e73a5 0x3717afed 0x31384743 0x2e01 0x2dc0)
The Code itself doesn't stop in my sourcecode but in line "int retVal = ..." with an SIGBART signal received.
int main(int argc, char *argv[])
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
int retVal = UIApplicationMain(argc, argv, nil, nil);
[pool release];
return retVal;
}
Can somebody please tell me if i can get back my used stacktrace, where at least I can look up in which line my app crashed?
Thx in advance,
Maverick
Its fairly simple:
-[__NSArrayM insertObject:atIndex:]: object cannot be nil
If you want to track it down and you know the steps, it would not take too long to guess which "insertObject" call is being given a nil pointer.
For getting proper stack-trace, have you tried cleaning the build? Also, try with breakpoints on. (and make sure you are not using a beta version of XCode).
You’re not assigning an app delegate to UIApplicationMain. Is this deliberate?
If not, and if you’re using Xcode 4.2 and iOS5 SDK your main must look like:
int main(int argc, char *argv[])
{
#autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
From what I've seen you can't actually symbolicate the call stack anymore, but you can work around the issue. Check out this answer if you don't mind changing your application code or use the graphical call stack in the Xcode window's Debug Navigator.
How can i catch sigpipe in iphone/objective-c?
thanks
One important fact for testing the SigPipeHandler:
For me it did not work when the debugger was atached. So when running an app directly from XCode the Handler is not called.
Meanwhile, on a device without the debugger attached the handler works as expected.
Use old good POSIX code:
#include <signal.h>
void SigPipeHandler(int s);
void SigPipeHandler(int s)
{
// do your handling
}
Init in some place (main.m?) with
signal(SIGPIPE, SigPipeHandler);
Try setting SO_NOSIGPIPE as documented here:
How to prevent SIGPIPEs (or handle them properly)
The first answer doesn't work.
Also I'm trying to use solution described in reference of second post:
int main(int argc, char *argv[ ]) {
struct sigaction mySigAction;
mySigAction.sa_handler = SIG_IGN;
sigemptyset(&mySigAction.sa_mask);
sigaction(SIGPIPE, &mySigAction, NULL);
...
}
but this code doesn't work too. Anybody know solution of this problem?
The first answer works fine. but you should put every thing in the main.mm file.
And in static class(Singleton) , it also works.
#import <UIKit/UIKit.h>
#import <sys/signal.h>
#if TARGET_IPHONE_SIMULATOR
#endif
void SigPipeHandler(int s)
{
NSLog(#"We Got a Pipe Single :%d____________",s);
}
int main(int argc, char *argv[])
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
signal(SIGPIPE, SigPipeHandler);
int retVal = UIApplicationMain(argc, argv, nil, #"FullAppDelegate");
[pool release];
return retVal;
}