Implementing Testflight.com and Flurry.com exception handling

Question

We are using both testflight.com sdk and flurry.com sdk to track unhandled exceptions. The issue is that no exceptions are picked up by flurry after we added the testflight.com sdk.

The method triggered when an unhandled exception occur looks like this:

void uncaughtExceptionHandler(NSException *exception) 
{
    [FlurryAnalytics logError:@"ERROR_NAME" message:@"ERROR_MESSAGE" exception:exception];
}

- (BOOL) application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions 
{    
    #if !TARGET_IPHONE_SIMULATOR
    NSSetUncaughtExceptionHandler(&uncaughtExceptionHandler);

    struct sigaction newSignalAction;
    memset(&newSignalAction, 0, sizeof(newSignalAction));
    newSignalAction.sa_handler = &signalHandler;
    sigaction(SIGABRT, &newSignalAction, NULL);
    sigaction(SIGILL, &newSignalAction, NULL);
    sigaction(SIGBUS, &newSignalAction, NULL);

    [FlurryAnalytics startSession:kFlurryKey];
    [TestFlight takeOff:kTestflightKey];    

    [[UIApplication sharedApplication]
     registerForRemoteNotificationTypes:(UIRemoteNotificationTypeBadge |
                                     UIRemoteNotificationTypeSound |
                                     UIRemoteNotificationTypeAlert)];    
    [UIApplication sharedApplication].applicationIconBadgeNumber = 0;    
    #endif
    .
    .
    .

I'm not sure how testflight.com does it, but it seems like they intercept the exception and register the data for themselves without letting the registered method be run?

Are there any way for both of these to coexist?

Patinated

I haven't tried to be honest. I'm not coding much cocoa nowdays, so my focus are elsewhere. – Fons

Answer 1

I got confirmation from the Testflightapp.com team that this is a known issue. They hope to fix in in the next version they said.

Patinated

I use TestFlight, Crittercism, and Flurry. It turns out TestFlight continually overwrites any other exception handling. Atleast this is what Crittercism told me as they had the same issue and found this through debugging. – Myosin

Answer 2

I'm not able to test this directly, but the TestFlight documentation seems to say this:

If you do use uncaught exception or signal handlers install your handlers before calling takeOff. Our SDK will then call your handler while ours is running.

They even give some example code which might help you get this working.

Chromo

Yes, I know, and I am doing it the correct way as far as I can see. Editing original post to show how I've implemented it in my application delegate as well. – Fons

I would suggest asking TestFlight then if you're certain it's not working as I guess it must be a problem in their SDK not passing control to your defined handler like they say it should. – Chromo

Yea, got an ticket registered with them, and Flurry. Will post solution here if they are able to find the reason. – Fons

Answer 3

I have found a solution on a blog, not sure if it works for Flurry as well, what it says is to call UninstallCrashHandlers method (declared in TestFlight.h) twice after [TestFlight takeOff:@"KEY"] method, and then register other service for which you want to use for crash reporting. See example code for TestFlight vs Crashlytics

Disabling TestFlight’s crash reporting is quite simple. Add the following code your includes in AppDelegate.m:

...
#import TestFlight.h

// Function prototype for UninstallCrashHandler
extern void UninstallCrashHandlers(BOOL restore);

In didFinishLaunchingWithOptions call this method first with NO and then with YES, like:

- (BOOL)application:(UIApplication *)application
        didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
  [TestFlight takeOff:@"<TestFlightKey>"];

  UninstallCrashHandlers(NO);
  UninstallCrashHandlers(YES);

  [Crashlytics startWithAPIKey:@"<CrashlyticsKey>"];

  return YES;
}

ref: http://www.grahamdennis.me/blog/2012/10/21/how-to-disable-testflights-crash-handlers/

Mercia

If anyone can check and confirm this, I will mark the answer as the solution. I am no longer developing for mobile platforms, so I am unable to check myself. – Fons