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.
Related
I am trying to integrate unity to iOS application. I have followed this tutorial http://www.agnosticdev.com/blog-entry/swift/integrating-unity-and-vuforia-ios-swift-project
Now after integrating when i start my app it crashes and show this error on console : was compiled with optimization - stepping may behave oddly; variables may not be available.
Crash :
I have tried googling this and found these links :
APPNAME was compiled with optimization - stepping may behave oddly; variables may not be available
'Project Name' was compiled with optimization - stepping may behave oddly; variables may not be available
Xcode target compiled with optimization
Xcode: Cannot set optimization level for debug
and nothing changed.
I have changed optimization level of both project and pod.
I have also added this line to pod file : project 'MyProject', 'Debug - local'=>:debug, 'Debug - staging'=>:debug, 'Debug - PRODUCTION'=>:debug ( before target 'projectname' do)
Also I have unchecked Strip Engine Code in unity.
What can i do to overcome this error ?
Any help would be appreciated, thanks.
The code you're debugging is IL2CPP code, which is likely in a library prebuilt with optimizations (probably in libiPhone-lib.a). Your build settings only effect the code being compiled now in your xcode project, so they wouldn't effect a prebuilt lib. To get rid of the warning, you will need to rebuild that library, and you will need Unity source code to do that.
More importantly, it's not the cause of the crash. It's just telling you that it's going to be harder to find the source of the crash.
It looks like it's calling a function called LoadMetadataFile and crashing when accessing the return. You can probably set a breakpoint on that function call and see what's going in and out of it to find the next debugging step (the bl instructions 5 lines above the highlighted crashing line).
Here are some documents that might help you:
Apples calling convention docs:
https://developer.apple.com/library/content/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
Arm instruction reference (opened to the crashing instruction): http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0802a/LDRSW_imm.html
I had the same issue and I solve it adding to Apple LLVM - Custom Compiler FLags:
Other C Flags: -DRUNTIME_IL2CPP=1
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.
I just upgraded my xcode to version 4.5.1.
Everything worked fine before but now, when I Archive the project, xcode get stuck/hanging and never finishes the archiving.
In the status on top, the text says:
Compiling 10 of 10 source files...
Nothing happens after that. It is just stuck.
I can still compile and build the code (without archiving) and everything runs just fine in the simulator.
I have reinstalled xcode. The issue still happens after that.
Any suggestion will be appriciated.
More info:
I've pinpointed the problem to a specific line of code:CGRect tmpFrame3 = seeDetailsButton.frame;
I don't see any problem with this line...
Why would it work fine when building and running in the simulator but fail when archiving???
I figured out what is going on here.
First, it is not related to the archive process itself but to the build in Release mode.
The reason that I had the problem during archive is because then it builds in release mode.
About the issue itself:
It seems that there is some sort of an Apple compiler bug in xcode 4.5.1.
I'm using the Apple LLVM compiler 4.1. During compilation it has different optimization levels.
In Debug - the optimization is set to 'None' and is off. In release it is set to 'Fastest, Smallest [-Os]'. When I turn off the optimization in release mode (set it to 'None') - the issue does not happen.
More info:
After digging in my code, and trying to figure out what would cause a compiler bug during optimization, I saw that I had the following:
__weak ProfileButton *tmp = myButton;
Where ProfileButton is just a regular button inherits from UIButton.
When I remove the __weak everything works just fine. Even when I set the compiler optimization to 'Fastest, Smallest [-Os]'.
Recently faced this same issue, with Xcode hanging on the final file during compile. In the same fashion as the problem above, setting the optimization level for release to None ([-O0] to match the debug mode) would allow archive to run successfully.
However, for our code the specific bug was tied to a block that was capturing self. Per Apple's guidelines:
"If you need to capture self in a block, such as when defining a
callback block, it’s important to consider the memory management
implications.
Blocks maintain strong references to any captured objects, including
self, which means that it’s easy to end up with a strong reference
cycle..."
So be sure to check your code for this, if applicable, and follow Apple's best practice to capture a weak reference to self (example in documentation).
In my case I created a circlic subclass
It was like
#interface BaseTableViewController : PaymentTableViewController
and
#interface PaymentTabelViewController : BaseTableViewController
What i did was to reneme the last subclass, so it now looks like this:
#interface TopTableViewController : PaymentTableViewController
and
#interface PaymentTableViewController : BaseTableViewController
In my case the issue arose when one of source files contained a declaration of a very large array like this:
NSArray<NSArray<NSNumber *> *> *points =
#[
#[#38.576732f, #-90.230682f, #1495320246], // 1 item
...
#[#37.478034f, #-89.524851f, #1495336147] // 3000 item
];
There were about 3k items. Splitting the source line into small ones doesn't helped.
Fixed it by placing items in a CSV file and parsed it at run-time.
Another approach could be splitting into smaller arrays and concatenating at the run-time.
My app was crashing only when not running using XCode debugger. It was hard to track because I can't debug but I finally figured it out. It was because of calling release on some object not owned by me. Before I corrected it I searched and found 2 related questions here (links below)
iOS App Crashes when running by itself on device, does not crash when running through Xcode using debugger, or in simulator
iPhone crash only when device not connected to xcode, how to understand the crash log?
None of the above question has answered why no crash when running via debugger.So my question is why it happens ? I know reasons for debug/release specific crashes but this is crazy. Is it just by chance although it happened more than 10 times.
What you describe is not atypical of obscure memory-related bugs. You might also want to use debug-malloc at such times. Although that is not guaranteed to find everything. The reason (and it's been happening probably as long as there've been source-level debuggers) is that memory is laid out at least somewhat differently in debuggable code, and when running under the debugger. So the error results in a different piece of memory being (harmlessly) corrupted when under the debugger. When not under the debugger the location corrupted is actually something that your code cares about, and it crashes.
The same could happen in reverse, but you'd never know - if it crashes when run debuggable, you'd find it before switching to running outside the debugging environment.
Reiterating #jyoung's answer since I didn't see it the first time I glanced through:
Try running with Zombie Objects turned off.
In debug mode if you have it turned on it is handling memory allocation differently. Try running it without.
Go to Edit Scheme... > Run > Diagnostics. Then make sure zombie objects is turned off:
Then run through your code path again.
I had this same issue while working on a project modularised with Xcode Frameworks. Even after removing all the logic in AppDelegate and only returning true inside application:didFinishLaunchingWithOptions, I was still getting the crash. Then I switched to my project settings, in the Frameworks, Libraries, and Embedded Content section and changed the embed option for the frameworks I added to Embed & Sign. This was what fixed the issue for me. I hope someone finds this helpful.
I was having this problem as well and was fortunate to figure out the cause quickly, hopefully by posting here I can save someone else some wasted time. To clarify, my app would run with no issues when launched directly from XCode, but would crash immediately when launched manually on the iPad.
The app in question is written in Obj-C but relies on some 3rd party code written in Swift. The Swift code is included in the app as an embedded framework. I had to set "Embedded Content Contains Swift Code" to Yes in the Build Settings for the app (under Build Options), then the problem went away.
I experienced this symptom when I made a NSString, sent a UTF8String from it to another object, and assigned it to a char pointer. Well, it turns out that I forgot to retain the original NSString, which wouldn't have mattered anyway, since I also failed to realize that the UTF8String method (which is presumably an object that gives access to the pointer itself) operates in the autorelease pool. That is, retaining the NSString itself did not fix the problem.
I suppose this appeared to work just fine when attached under the debugger only because I had zombies enabled, so the pointer I had was still valid. I should see if this is the reason it worked; if so, this is a good reason to test with and without NSZombie enabled.
At any rate, this was probably poor design to begin with, and a pretty obvious newbie memory management mistake once I found it. Luckily the console in the Organizer window gave me some hints on where to start looking, and debugging ultimately showed me where my pointer's value was changing. Hope this helps anyone who finds the way here.
I had this issue when accessing SQLite databases from outside the [[NSBundle mainBundle] resourcePath] directory, which caused iCloud errors.
I discovered the error only by installing a Console app onto my iPhone which logged the errors.
Once I accessed the databases from the correct directory, the errors disappeared and the application booted correctly.
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.