iOS - Application crashes when using optimization - ios

When i build my app with any optimization level other than -o0, the application crashes at some point because of EXC_BAD_ACCESS. I tries all possible optimization levels (-o1/2/3/s) and all crashes the application.
The compiler is LLVM 3.0.
Any idea why it happens? Is this some known issue?

I would check for uninitialized variables as a possible cause. The different settings causes things to move around and something that is "safe" in the unoptimized build could hold a stale pointer in another.

Related

Static Library works fine with debug,but does not with release

I have an iOS project which has a static library and in the library there is a encrypt method and in the method it refers a lot of system encrypt method about AES encryption. When I build the static library with release,it returned the correct data.But when I build with debug mode,it returns nil.
What's the differences between the two modes?
The same source code can build out different binary files that works differently?
Help me,thanks beforehand. This is where I choose the two modes.
The main difference is the level of compiler optimization. Select the project target and look at the Build Settings and compare Debug to Release.
One potential reason for the crash is that the code has some memory usage errors that by coincidence do not cause a crash with code optimization but do with no optimization. Or there are some other configuration difference. See the comment by #iDev.
A starting point is to fix all warnings, both compiler and Analyzer. The examine the crash log to understand the crash. If you need help with that add a crash report to your question.

use ARC library in non arc project

I am developing an IOS application. I don't use ARC, my project is non ARC project. Bu I'm using a library developed for the ARC. This librar is AFImagePager. This librar is image gallery. So I added a flag What is -fobjc-arc at required file. But when running the application gives memory error. Memory usage is constantly increasing, not decreasing at all. Is this normal
You don't have to enable ARC for your project, using ARC isn't just a matter of adding -fobjc-arc, it's more involved than that.
The only thing that you can't do if you use a library that is ARC, is use GC, because that's not compatible.
If your project was MRR and working fine, continue to do so.
For your application, make sure you are doing proper memory management. That is the only thing that I can think of that might be causing those errors. Tip: go to Product -> Analyze… and check on all the memory issues it reports.

Receiving signal SIGTRAP after instruction "svc 128" on iOS 6.1

Every once in a while, while debugging an application on an iPad (OS 6.1.3, SDK 6.1), the program pauses after receiving a SIGTRAP signal. I first noticed this happening inside the stat function (from /usr/include/stat.h), but it's also happening in a few other places, like semwait_signal (from nanosleep). The most obvious pattern is that it always happens immediately after running the instruction svc #128. In the case of stat, it returned 0 and there were no errors, so it doesn't seem to indicate any kind of failure state.
Has anyone else experienced this, or know how to get around it?
Thanks!
Unfortunately I didn't discover why exactly the SIGTRAP was being raised by these basic functions, but this symptom went away when I fixed a larger problem with my iOS project.
The app target and static library targets I was linking in didn't consistently define the preprocessor macro _DEBUG, which generated some weird assembly. They had the same levels of optimization, but apparently including/excluding _DEBUG made enough of a difference to cause problems.

Crashing on simulator, not on device

My app crashes (randomly by the way) when running on the device, the crash is not reproduce-able 100% of the time. But it only seems to occur on the device, not in the simulator.
When I run in the simulator with NSZombies I never see problems. Could someone shed some light into my points below.
Device has limited memory, maybe it's crashing because of this.
What would be considered a big memory allocation that would cause a crash?
Would memory leaks/big allocation cause a memory corruption?
All my crashes are always EXC_BAD_ACCESS but like I said, never happens on simulator so I can't run zombies. (or is there another way?)
Note I have also simulated low memory warnings on the simulator to see if that's causing issues.
This is driving me nuts. Any help would be appreciated.
I know where it crashes but I need to know which other classes released this object.
Override -[release] -[autorelease] and -[retain] for your object (or you could do this for NSObject if you didn't know which object), then log them, set breakpoints.
If you identify which object is being released at each point, add timestamps/ object IDs/retaincount to the log statement, then you might be able to throw all of the data into a spreadsheet and then to get the same sort of data that Instruments would give you.
Shame you have to build for 3.0. Almost nobody uses 3.x anymore, and ARC (while not a silver bullet for all issues) is way better than non-ARC.
Also here's a tip: delete the app from your simulator and reinstall it. I had an issue where some of my bundle resources were missing in my project but the Simulator was hanging onto them between builds. If you tried to load a .xib that is no longer in your project, I could see it crashing...

Xcode LLVM 3.1 and GCC_OPTIMIZATION_LEVEL

I have an Xcode 4.3.2 iOS 5.1 project that compiles and runs fine when my build configuration uses a GCC_OPTIMIZATION_LEVEL of None [-O0], but fails with a EXC_BAD_ACCESS error when using any other optimization level. My project has GCC_VERSION set to Apple LLVM 3.1 (the default). Does this indicate a problem with my code?
Most often it indicates problem with your code. Like:
accessing already deallocated memory
reading or writing memory out of bounds of allocated array
using non initialized variables or class members
and many many others...
In rare cases it happens that such kind of crash turns out to be a compiler bug. But that is rare. More often that is problem with your code.
Try to pinpoint code that crashes and try to see how variables are used nearby that code. Check if everything is used/allocated/initialized/freed correctly there.

Resources