7

Consider the following objective-C++ code

- (BOOL)application:(UIApplication *)application
        didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    try
    {
        throw std::logic_error("error message");
    }
    catch (const std::exception& ex)
    {
        NSLog(@"%s", ex.what());
    }
    return YES;
}

In XCode 6.2 it is working as expected ("error message" is logged). However since we upgraded to 6.3, the throwing line (throw std::logic_error...) raises SIGABRT (the stack trace only contains _cxa_throw and _pthread_kill beyond applicationdidFinishLaunchingWithOptions) and crashes the application.

This only happens in our application - when I copy the exact same code to a new project everything works well, even with identical compiler flags.

I've tried specifying -fexceptions and -fnon-call-exceptions to no avail (same behavior).

Update It seems this only happens on 32-bit simulators (it works on actual devices and 64-bit simulators).

Update 2 We narrowed it down to the UserVoice iOS SDK. The behavior is clearly displayed in a new vanilla project simply by linking against it (make sure you call some method so that linkage takes place). We haven't investigated what exactly in that library causes it yet, and we also have some internal libraries that provoke the same behavior (but they should be irrelevant to anyone outside Microsoft).

Ohad Schneider
  • 36,600
  • 15
  • 168
  • 198
  • Same for debug vs. release? Can you look the compiler's output to see if it matches between 6.2 and 6.3? That might at least indicate if it's runtime and not compiler. – KirkSpaziani Apr 13 '15 at 16:07
  • Also add a catch(...) to see if you're catching *something* – KirkSpaziani Apr 13 '15 at 16:11
  • @KirkSpaziani same thing in both debug and release. The compiler output simply says *libc++abi.dylib: terminating with uncaught exception of type std::logic_error: error message* (obviously this line is not present in 6.2 where the exception is properly caught). Adding `catch (...)` doesn't make a difference. – Ohad Schneider Apr 13 '15 at 16:33
  • Are you using any frameworks/cocoapods? e.g. crash handlers? It's just that the lack of detail about what's different between your app and a plain old vanilla app is vast, and you've not really given any hints – Anya Shenanigans Apr 13 '15 at 17:03
  • try using an objective-C++ `@catch`, according to the docs that should work better as it can (in the latest version at least) catch C++ exceptions – Mgetz Apr 13 '15 at 17:11
  • @Petesh we're actually using a crash handler, that's a very good hunch I'll check when I'm in the office. Of course the difference between our app and the vanilla app is vast, this is exactly the reason why the issue is so hard to debug. If you think there's anything else I should add (besides dependent frameworks which I will when I get to the office) please let me know\. – Ohad Schneider Apr 13 '15 at 21:20
  • @Mgetz using `@try`/`@catch(...)` results in the same behavior I'm afraid – Ohad Schneider Apr 14 '15 at 09:19
  • @Petesh Sadly disabling the crash handler doesn't work. As for other dependencies, we use some standard and internal libs for authentication, networking, serialization, and telemetry. Nothing in particular stands out, but I guess we'll start a binary search for the culprit. Also see the update in the question - seems like we're only getting hit in 32-bit simulators. – Ohad Schneider Apr 14 '15 at 12:03
  • Same thing happening for me. It seems [Apple changed something related to C++ exceptions in Xcode 6.3](https://twitter.com/depth42/status/586548205753602048) but didn't bother documenting it in the release notes. – Guillaume Algis Apr 17 '15 at 13:23
  • This is especially frustrating as the only iPad 64bit simulator is the iPad Air, and its retina resolution makes it so slow it's unusable. – Guillaume Algis Apr 17 '15 at 14:06
  • @GuillaumeAlgis we narrowed it down to the UserVoice iOS SDK: https://github.com/uservoice/uservoice-ios-sdk. If you're using it, you'll get this behavior for sure (we actually have some more internal libraries that provoke this behavior, but they are irrelevant to anyone outside MS). – Ohad Schneider Apr 17 '15 at 14:50
  • @OhadSchneider It's one of our internal lib which is causing it too, no way we can function without it sadly :(. I guess the only option here is to file a Radar and wait... – Guillaume Algis Apr 17 '15 at 14:55
  • @GuillaumeAlgis were you able to isolate what exactly in that lib caused this behavior? In the UserVoice SDK it has to be some global initializer (as it happens before any UserVoice code is called), maybe your internal lib is doing something similar... – Ohad Schneider Apr 17 '15 at 14:59
  • @OhadSchneider I was not able to isolate a source for the bug; and I'm not able to replicate it with a new project linking UserVoice... Could you share your crashing minimal project please ? – Guillaume Algis Apr 17 '15 at 16:10
  • Another SO question on the same issue: http://stackoverflow.com/questions/29646999/try-catch-doesnt-catch-exception and a thread in the dev forums: https://devforums.apple.com/thread/267548?tstart=0 . No much more info in these though. – Guillaume Algis Apr 17 '15 at 16:31
  • @GuillaumeAlgis I don't have access to my Mac right now but basically create a new project in XCode, link the latest UserVoice lib (https://github.com/uservoice/uservoice-ios-sdk/releases/tag/3.2.3) add the snippet in my question and call something from the SDK (e.g. init some UserVoice object). – Ohad Schneider Apr 17 '15 at 19:38
  • Sounds like a bug in the 64 bit simulators when running 32 bit binaries. I ran into this issue as well and only once I enabled 64 bit builds did exceptions catch correctly. – Eric Buehl Apr 17 '15 at 21:57
  • The question is, what exactly triggers this bug and can we work around it (our build is not ready for 64 bit yet)? There is something in the libraries I mentioned that provokes it.... – Ohad Schneider Apr 18 '15 at 07:50
  • Did you ever find a fix? I'm getting the same problem when using a few different 3rd party libraries... – luna_ May 05 '15 at 19:29
  • @luna_ other than not using 32-bit binaries in the 64-bit simulators, I'm afradi not. Here's the latest word from who appears to be an Apple dev in their forums: *The problem should be fixed in the next beta release of Xcode 6.4. In the meantime, you might be able to avoid the problem by rebuilding all of your object files with the latest tools. Some of the reports that we've looked at show that the problem is exposed when using static libraries or other objects that were generated with older tools.* – Ohad Schneider May 06 '15 at 07:40
  • Thanks for the response. So, is it just a simulator problem? I don't have any 32-bit devices to try on. – luna_ May 06 '15 at 08:16

2 Answers2

0

I've found 6.3 to be filled with serious bugs. Upgrading to 6.3.2 seemed to fixed all of my problems. Give that a shot.

ninjaneer
  • 6,951
  • 8
  • 60
  • 104
  • I just tested 6.3.2 and I'm afraid the issue is not resolved. As far as I could tell from the apple developer forums thread (https://devforums.apple.com/thread/267548?tstart=0) it will only be resolved in 6.4. – Ohad Schneider Jun 01 '15 at 11:59
0

Apparently this issue was an XCode bug (linker specifically). It was reportedly fixed in XCode 6.4b3. I'm using 6.4 (6E35b) and indeed it seems to have been resolved.

Ohad Schneider
  • 36,600
  • 15
  • 168
  • 198