views:

256

answers:

4

Hi there. A project i'm working on is crashing when built with release configuration.

We need to send the application to apple for review and it is crashing before even entering the app.

Any idea how that could happen?

In last ressort, is it possible to send to apple a debug version of the app with some optimizations?

thanks.

+1  A: 

The same thing happened to me when building my first iPhone app - after working on the project for a while when switching from debug to release the app would crash. I did a full clean rebuild of the project, deleted the app from the test phone and reinstalled it, and the app ran. It looked like XCode sometimes does not clean up/rebuild everything it needs to.

thanks for the advice, going to try that one as well, hope this will as easy as you are explaining.
Diallo
That may be true, but could also be a red herring if the underlying cause is a memory leak or some other memory/pointer related issue that you're side-stepping due to things being aligned in memory slightly differently after you clean.
Chris Ingrassia
Thanks for your help.it was much harder to make it work but now it is working.I've done so much things that i don't know what solution actualy worked well.but as i didn't changed any line of code i'm marking your solution as accepted.
Diallo
A: 

If you build with Release configuration, make sure you keep a copy of the .dSYM file and the application bundle.

Then when the application crashes on the device, plug it into Xcode and download the crash reports.

Open Xcode and then open the Organizer from within Xcode. From there you can view crash reports from a device.

The crash reports will be symbolicated if (and only if) you saved the .dSYM file and the application bundle.

You can then use the crash reports to find out why it is crashing, and fix it.

Jasarien
A: 

You should look at your Crash Logs. Open Organizer, select your device, then the "Crash Log" tab. Scroll down to find your app's logs. The should be symbolicated, so you can see the stack trace.

Without actually debugging your app, it's really hard to say more. Are you using an #ifdef DEBUG macros? Are you using more than one thread? If you have a bunch of NSLog statements that slow down execution in debug mode, this can introduce subtle timing differences that can impact multi-threaded apps.

Did you try a 'make clean' on your debug version? Sometimes obscure bugs can be hidden when parts of your project are rebuilt while other parts are unchanged.

Zack
will look at the crash log.i'm not using #ifdef anywhere and yes i have a multithreaded program (but i've made sure any data modification is made in the main thread) and threads are not communicating directly.
Diallo
That will go a long way. Be cautious about reading data from your secondary threads. Even if you are using NSLock, or only writing data from your main thread, try not to make assumptions when you read from your secondary thread. For example, check that the object you need actually exists before using it. The main thread may have already released it by the time your secondary thread accesses it. These kinds of timing errors can avoid detection in slower debug code, but rear their ugly heads in release code.Chris's suggestion regarding using static analysis below is sound advice, too.
Zack
A: 

In my experience, 9 times out of 10 annoying, hard to track down crashes in a non-debug vs. debug build of anything, iPhone or otherwise, is caused by a memory management bug. I'd put money on your issue being caused by an improperly placed release or retain message, or lack thereof. If you haven't tried it yet, turn on the static analyzer in your debug build configuration (my XCode is updating right now, but I believe if you search for "analyzer" or "clang" in your build properties you should find the appropriate setting) and see if it points to anything telling. If it doesn't, you can use Instruments to help you check for problems, as well as attempting to isolate the problem area in the debugger.

It might help you to reproduce the problem in a not-actually-a-release-build by modifying your debug configuration or duplicating it to use a different set of compiler flags that more closely aligns with what happens in the release build (I don't recall what the differences are off the top of my head, but I would assume adding a "-O2" to your compiler flags would get you most of the way there).

Chris Ingrassia