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.
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.
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).
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.
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.
Related
So, my problem is that I'm creating a framework to be used with iOS. It works great when in the simulator and when I'm debugging it on my iPad but as soon as I send it to anyone via Testflight (including my iPad) it crashes. The application will load the splash screen, then crash.
I tried symbolicating the report but I'm not getting anything out of it.
One time happened to me... xcode compiles the app for debug on the simulator, but for release on the iOS device. Then, the debug version doesn't do many enhancements.
Go to "Product" -> "Manage Schemes". There, if I were you, I would set everything to "Build Configuration": Release.
This way, you may be able to have the simulator crash... and it may be easier for you to figure out what's going on.
In my case, I was using a block but not copying it... then, on the release version, the compiler cleared the memory while on the debug version it didn't.
Hope it helps
So, the solution to my problem was that I was linking the framework but not copying it to the device, so when I debugged it with my iPad connected to it, it would find the references to the framework, but once it was deployed, the app crashed when it tried to find the framework.
The answer was:
Go to your project's build phases.
Add build phase > Add copy files.
Choose Frameworks in the Destination field.
Copy the framework.
Your app should now have the framework copied and installed wherever it needs.
I have an app that is crashing on the device (works well in the simulator) which leads me to assume that maybe it's a memory issue...
When it crashes, there is no message whatsoever reported in the console.
It does not crash each time a certain action is taken, it crashes at different points of time always after the app has been running and in use for some time.
I know I'm supposed to ask a more specific question - but if anybody is able to tell me where to start trying to track down a crash that does not report in the console, I would really appreciate it!
I am now using the latest version of XCode (4.2)
Thanks in advance...
It very-well could be a memory issue. If that is where you want to start your diagnostics, you can use the built-in Xcode profiler. In Xcode Product->Profile will get you started.
Maybe setting the NSZombiesEnabled value to YES in Project -> Edit Active Executable -> Arguments -> Variables is also helping; this will show you memory access errors based on accessing released objects. But in that case you should at least get a SIG_ABRT or BAD_ACCESS error ...
You can also log when the app receives a memory warning in the didReceiveMemoryWarning functions of your view controllers - this is called before the system is throwing out stuff when memory gets low. That of course could lead to a crash with nothing showing.
First, relax.
Then read this Technical Note.
Now, follow these steps:
From /Users/<username>/Library/Developer/Xcode/DerivedData remove all folders.
From /Users/<username>/Library/Application Support/iPhone Simulator remove all folders.
Clean your trash.
Remove app from device.
Build and run application on device.
Follow the steps that leads toward a crash.
Now, go to XCode->Window->Organizer and select "Device Logs" your device from the DEVICES pane. Select the most recent of these which has your application's name. Wait for XCode to symbolicate the crashlog. There are two possibilities now:
Its a low memory crash.
Its a memory management related crash.
If its option one, profile your application in Instruments.
If its option two, you should see the stack frame where you application is crashing (or your module's stack). This SO question will be very helpful
If you cannot understand the output (or you think the crashlog is not symbolicating - or that its not your code that's crashing), please post the crash log's crashing thread's stack here and I'll look into it.
PS: in the first section we do the first two steps to make sure there are no left-over .app/.dSYM files which might hinder symbolication later in the process because XCode symbolicator is not that intelligent.
I've imported an iPhone app that I have developed for iOS and am now maintaining it. I've came across a couple of bugs when trying to add to the iPhone's calendar, which I'm happy to try and sort out myself with a bit of debugging.
One problem is that when I go to run the application on the iPhone simulator, it seems to run an older version of the app than the one I am running. I've removed and added another button since then and the old button is still showing when I run it in the simulator. However, when I compile and run this on a device, it loads the correct version and displays the correct version number in the 'about' view.
But... my main problem is that it doesn't seem to debug on the device properly. The app actually works fine except for the calendar problems, but if I put a few breakpoints in so I can see exactly where this is going wrong, it just doesn't seem to step through! The app pauses, and Xcode says the app has paused! I can press step over and continue execution etc and it appears to work, but I can't see it stepping over the code, nor can I hover over variables to see their values.
I've tried reinstalling Xcode multiple times (I did have a problem installing an older version, so I had to wait until the next version was available before Xcode would install).
The stress is: Today is my last day at work, and I'd really like to get this app ready for iOS 5 before I leave.
Has anyone seen these symptoms before? Is there a debug setting that I've missed? Or is it a corrupted installation?
I wish I could help people a bit with more information, but I don't even know where to start looking here. Any code I can post? any settings? (not too familiar with this, I'm a .NET guy usually).
Thanks!
Sorry you're going through a tough moment there Connell; as you said you're not too familiar with all this, I'm laying down a few steps which might help you out. Some are pretty basic, yes, but I've resolved to these steps myself several times when I've encountered similar scenarios;
If you're testing on the simulator, do a 'Reset Content and Settings' from the 'iOS Simulator' main menu. This will remove all old data and settings and give you a clean start.
Do a 'Clean All Targets' from the Build menu. Then go to your physical project folder and delete the Build folder from it altogether before starting to build again.
Restart both XCode and the Simulator (and your Mac too if possible)
Make sure the mode is set to Debug and not Release or Distribution
Even on the device, remove the old app before putting the new one in, and restart it for good measure.
Delete all Provisioning Profiles from the device and install just the one you need.
On the code;
I've noted that the app appears to 'pause' like this a couple of times when I had accidentally created an infinite loop in the code. Double check to see whether there's something which may cause this.
Unless you haven't already done so, throw an NSLog or two in there to see if its really not being executed beyond the breakpoint.
I've had the exact same problem with a project that I started on xcode 3 and then switched to xcode 4. What fixed it for me was changing the compiler in the project settings.
The default compiler up to xcode 3 was gcc, while the default compiler on xcode 4 is LLVM gcc.
Now, I don't know exactly what's the issue that gdb could have with LLVM gcc, but switching the compiler back to gcc in my project settings and doing a clean build fixed my debugging issues.
Might be worth a try.
Have you checked which debugger is being used GDB or LLDB? Select Edit Scheme from the Product menu, and see what the Debugger setting is under the Debug scheme. You could try switching between GDB, LLDB, and None and running in between.
After submitting our application several times, we continue to receive the following response:
Thank you for submitting My App to the
App Store. We've reviewed your
application and determined that we
cannot post this version of your iPad
application to the App Store because
My App is crashing on iPad running
iPhone OS 3.2 and Mac OS X 10.6.2. My
App crashes upon launch.
Unfortunately, crash logs have not
been generated.
However, resigning the same build with the AdHoc entitlements and loading the build onto the device yields no such crash. After a number of attempts, the application simply does not crash as reported by the reviewer. Furthermore, the reviewer does not provide any useful logging that may have been generated by SpringBoard such as an exit status or event if it had worked properly for any other device. There are no calls to explicitly exit or quit the application in the code line and yet the application terminates on startup.
What might cause an application to terminate in such a manner?
Under what conditions is an application tested that might not be found under a development environment?
Could it be a result of a signing issue that the submission validation system is simply unable to catch?
Thanks in advance.
After fighting with this for weeks, the application has finally been approved. The key: signing corruption. Hence why the application would start (or at least appear to start by showing the splash screen) and then suddenly vanish without a crash log. It failed Springboard's preflight sighing check.
A good tool to keep in mind to check for signing issues. It tells if the application has a valid signing:
codesign -vvvv MyApp.app
When I built the application, I would cp it to a network storage device where our product manager would pull it down and submit it to Apple. If decompressed on the NAS, the code signing was valid. But if you coped the compressed application back off the NAS and validate it, it would fail.
The lesson: make use of the new XCode utility to submit applications.
A few suggestions:
Try to use the leaks tool of the static analyzer to see if there are any memory leaks or problems your not seeing.
Does your app use a web service? This happened to me one time because the day Apple was reviewing the app the web service went down. That cause a crash. If thats the case you would want to add something to catch that.
Finally, In the logs Apple sent you did they send you the dsym file? If they did you can run atos from the command line and it will convert the address to symbols. That will show you what thread and symbol it's crashing on.
Be sure you test with a variety of settings: with Wifi disabled/enabled, with 3G disabled, Airplane mode on/off, location services disabled, etc.
As a last resort, assume there is a problem in your code that executes at startup. Remove half your startup code, set your release date in the far future (just in case it gets approved), then resubmit and see if they have the same problem. If not the problem is in the half you removed... it's a binary search.
I think you have two options: try harder to reproduce the defect using the tools other people are mentioning or to catch those crashes in the field.
PLCrashReporter will trap on an uncaught exception and store all relevant information. Next time your app is run, it can send the crash report that you can then symbolificate and view a stack trace of.
Ouch! That's a tough one. I've had this kind of thing happen before, but it seemed it was reproduce-able when I switched to a different device (iPhone 3G vs 3Gs, etc.). In your case though, it sounds like you're iPad only, so that might not help. There's a difference between 3G and Wifi, I suppose, but I would be really surprised if that was causing a crash on one and not the other.
One thing you could try if you think Apple's not doing their part is to change the binary name and re-submit it under another app name/record. See if you get the same response. If you get the same reviewer, you might, but I think there's a good chance you would get a different reviewer with a new app. Just set your app release date to some time in the distant future and it will never actually show up in the app store if they approve it. If the new app comes back rejected for the same reason, you've got work to do, but if they do in fact approve it, then I would get on the phone with them and point out the discrepancy.
My approach would be to make sure that the compilation is absolutely clean both in the static analyzer (this is NOT optional, it will save you time!) and for the build itself. Then set everything as described on CocoaDev' NSZombie page. Then make sure you have an iPod running 3.2 (actual hardware, not simulator) and test, test, test. Do it with network available and not available, with the device nearly full and freshly restored, every other variation you can think of. Run it with the debugger active and as a release build disconnected. Use Leaks, Instruments and all the other tools to peek in there and get a better feel for what is happening. If you exhaust every possibility you are going to have to beg for more detail from Apple but I bet you find a problem - one of the most important things in debugging an issue like this is to try to forget everything you think you know for sure and start at the beginning.
I have an iPhone app that's been in development for about 2 weeks. We recently tried the "release" version of the build on a device, and to our great unhappiness, it crashes in one of the views with an "EXC_BAD_ACCESS".
This crash only occurs on devices, and only in the "release" build. Not only that, but it only happens the first time the app is launched! It is also 100% reproducible.
We have removed the small block of code that deals with data persistence, and have tried re-openning Xcode, cleaning the project, deleting and reinstalling the app, etc., as some other questions suggest.
Do you have any advice for a) what might be causing this problem, and b) how to go about debugging if it only happens in "release"?
Thanks
It turns out there was no problem in the code at all.
The reason it was crashing was that Xcode was trying to attach the debugger to the release build for some reason! We are still trying to figure out why, because we have checked the most obvious places, but I'm sure it won't be too hard to track down.
The build works fine if you install from iTunes or the Xcode organizer instead of building and running from Xcode directly, so it won't affect your end-users at all, as long as you are careful to check for other first-run issues.
We can only guess what the cause might but if it's 100% reproducible, then it should be a good candidate for some fprintf-style debugging.
Figure out the most probable place for the error to occur, and start putting "Got past xxx view initialization" style statements in to start narrowing the problem. It's tedious, but eventually, you'll get there.
In theory fprintf statements could affect the problem. However, it's rare that it does so, so it's a good place to start.