Bad system call: 12

[fuggly]

Hiyas

I have a very strange issue using a real framework (years later, how can I find out whether the framework was created as real or fake framework anyways?) on a device only. It works perfectly in the simulator but also when I debug directly on the device, it works flawlessly as well. It only appears when deploying an app using the AppStore or TestFlight. I narrowed it down (so far) to simple C functions. First I thought it happened only with static C functions, but it looks like it also happens with normal C functions as well. When it happens the app simply crashes with a strange "Bad system call: 12" in the console. For example, when using the SSToolkit and moving that into a separate framework, the app using an SSGradientView will crash as soon as the C functions in CCGradientView.m are called.

I found a question on Stackoverflow where a guy apparently had a very similar problem, but could solve it by using no static C functions. In my case there aren't any C functions at all though. Is there maybe already a solution for this that I missed?

Best regards, Rog

[kstenerud]

I've been chasing this bug for awhile now since it affects one of my projects and I have solid repro cases. Here's what I've found so far:

• The crash only occurs on the device.
• It only occurs when you build for deployment (ad-hoc or app store), not if you launch directly from Xcode to the device.
• It only happens if you build the framework using CLANG, not GCC.
• Passing the address of a static function and then calling it will trigger this crash every time (changing the function to non-static fixes the issue in this case).
• Some low-level library calls will also cause it to crash (for example, signals).
• There are more problems with fake frameworks than real ones (I'm trying to address this in Mk 8 beta).

All in all, it appears to be a bug in CLANG/LLVM, probably stack corruption.

[fuggly]

Hiyas and thanks for the response

I can also reproduce this with non-static functions (SSToolKit, the helper functions there). Interestingly its enough to switch to static Objc-C class functions and they work flawlessly (but of needing to change the source).

What I also saw, is, that I have a lot of breakpoints and exceptions (but can continue) if I use the AV Framework (AVAudioRecorder, for example) to record voice data. Seems to be related as a normal application does't have that issue.

However.. is there maybe a workaround I could use somehow? To be honest, I don't really remember if I have a fake framework or a real one, but how can I find this out, after I already have a framework? And.. right now my project contains the two sub projects for the frameworks. Would it be enough to simply copy the framework files to the project and get rid of the "sub projects" I have now or is there actually a way to work around this that is known?

[kstenerud]

With a fake framework target, the target icon will be a bundle icon. With a real framework target, it will have a framework icon. Also, the Mach-O Type in the build settings will be "Relocatable Object File" for a fake framework target.

The bug will only surface on plain C calls (always when passing the address of a static function, and also in some library calls, probably because they pass addresses of static functions). ObjC methods use a different calling mechanism so they won't crash (though if an ObjC method in turn calls a C function that is affected by this bug, it will crash).

So far the only remedy I've found is to build the framework itself using GCC instead of CLANG (change the compiler build setting from "Apple LLVM Compiler" to "LLVM GCC 4.2" in your framework target). You could also try out Mk 8 beta and see if that helps.

[fuggly]

Hmpff.. yeah.. unfortunately that (LLVM GC 4.2) doesn't seem to work when, in your framework, you have both ARC and non-ARC'ed sources together (via -fno-objc-arc) as the compiler seism to be annoyed by using the parameter. Oh well... ;-)

[saniul]

@fuggly - Have you tried using Mk 8 Beta? Did it help?

[fuggly]

Not yet.. but I attended WWDC to try to get someone looking at it. Unfortunately, Apple's stance at this is: we don't support frameworks in IOS. We know some people are hacking something together but we don't officially support that. Of course we cannot say if and if yes, when we will support them, and so on. So basically I was leaving with the same knowledge as I arrived. I will try this (Mk Beta 8) out once I'm back from San Francisco (next week somewhen).

[samdeane]

I've had a similar problem in my own code. This StackOverflow thread helped me: http://stackoverflow.com/questions/10300800/ios-app-with-static-lib-always-crashes-on-launch-of-ad-hoc-archive-build-cant-r

In my case the crash was happening in when libdispatch called back into my block from a dispatch_async() call. The block in question was part of my own fake framework.