Crash on Archive binary

Luminary
Posts: 5,143
Joined: 2002.04
Post: #16
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.
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #17
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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #18
Are you using a "static framework"?

This thread suggests that's the root problem: http://stackoverflow.com/questions/99072...h-ipa-depl
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #19
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.

Root Project
|
|
---> Core
|
|
---> Otter

It sucks.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #20
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.
Quote this message in a reply
Member
Posts: 241
Joined: 2008.07
Post: #21
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. Smile
Quote this message in a reply
⌘-R in Chief
Posts: 1,254
Joined: 2002.05
Post: #22
(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.
Quote this message in a reply
Post Reply