Crash on Archive binary - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Programming Languages & Scripting (/forum-8.html)
+--- Thread: Crash on Archive binary (/thread-10040.html)
Pages: 1 2
RE: Crash on Archive binary - OneSadCookie - May 10, 2012 01:36 PM
That doesn't make a whole lot of sense. If that fixed the problem, there's something else going on. Some difference in the way the two versions are being built, or in the worst case, a compiler bug.
RE: Crash on Archive binary - bmantzey - May 10, 2012 01:40 PM
I know what you mean. I personally would lean towards believing it to be a compiler bug.
I found plenty of other info out there that pointed to the possibility of the static C function being the culprit, so I removed the static and it sure enough fixed it. There were 3 areas of the code, all which would produce an immediate crash, all which were using static C functions, all which were fixed when changed to non-static.
If you google "bad system call 12", you'll find more info about this, if you're interested. I found it in the console logs on the device, which I thought I'd look into.
RE: Crash on Archive binary - OneSadCookie - May 10, 2012 02:52 PM
Are you using a "static framework"?
This thread suggests that's the root problem: http://stackoverflow.com/questions/9907208/bad-system-call-12-crashes-when-using-a-static-framework-on-ios-with-ipa-depl
RE: Crash on Archive binary - bmantzey - May 11, 2012 09:21 AM
I'm not certain what is meant by a "static" framework. We do have an embedded project that creates a framework, which another embedded project links to as the root project compiles, wraps it up, and puts a bow on it.
RE: Crash on Archive binary - OneSadCookie - May 11, 2012 02:33 PM
I think on iOS all frameworks are static frameworks, since it doesn't allow dynamic linking for some reason.
Anyway, it sounds like there's a compiler bug where static functions in static frameworks don't work correctly. I'd just make a static library instead.
RE: Crash on Archive binary - bmantzey - Dec 4, 2012 03:03 PM
I know it's months after the fact, but I wanted to post an update. This problem is finally gone and hasn't reared it's ugly head once. The way the project was set up, as described in Post #19, the "Otter" project compiled that code into a framework, then the core project linked to that framework, then the root project built the core project. I looked at it and asked myself "why". I found out it had something to do with being able to give the customer the Xcode project without giving them certain source code.
Well, now that Xcode allows archives to be built, which do not reveal any source, the customer can take that archive and sign it for themselves. I removed Core and Otter and put their code in the root project.
Also, there was some kind of a library installed on the system that modified Xcode so that static frameworks could be understood. At the time, I was just hired for this job and had walked into a mess. It's so much nicer now.
RE: Crash on Archive binary - SethWillits - Dec 4, 2012 07:42 PM
(Dec 4, 2012 03:03 PM)bmantzey Wrote: Well, now that Xcode allows archives to be built, which do not reveal any source, the customer can take that archive and sign it for themselves. I removed Core and Otter and put their code in the root project.
Xcode archives are nothing more than the actual built products — your completely 100% compiled and linked ready-to-launch application — along with the dsym file for symbolicating crash reports etc.
The fact that Xcode calls it an "archive" doesn't change any of your original requirements. In the past, you could have always given the customer the built application for them to sign themselves. There's no need to give them source code to code sign. The code signing process takes the built application (not the source code) and signs it. You could codesign and redistribute any of Apples programs for instance.