Re: Bug related to GCC_OPTIMIZATION_LEVEL
Re: Bug related to GCC_OPTIMIZATION_LEVEL
- Subject: Re: Bug related to GCC_OPTIMIZATION_LEVEL
- From: Ken Thomases <email@hidden>
- Date: Tue, 1 Jun 2010 10:28:10 -0500
On Jun 1, 2010, at 7:30 AM, Jason Swain wrote:
> The bug presents itself as various Objective-c object variables being nil when they shouldn't be. I've added NSLogs() and they are all set correctly in a property setter in both Debug and Release, but when accessed later in the code they are nil in Release and correct in Debug. This is consistent and only happens in a few classes (with a common parent), so it is probably related to something in that class tree.
> Does anyone have any suggestions on how I should attack this problem?
This sort of thing is often an uninitialized variable or a stack or memory smasher.
The difference in build settings moves where things are stored. As a result, uninitialized variables can, by chance, be nil or otherwise "safe" in one case and hold a stale or garbage pointer in another. Similarly, stack or memory smashers change what they smash, possibly hitting something benign or unused in one case, hitting something important in the other.
In addition to Jonathan Mitchell's suggestion, make sure you compile with most warnings turned on (-Wall less a couple of things; search the archives for recommendations), and resolve all of the ones the compiler gives you. Also, use Xcode's static analysis (Build and Analyze) to see if it can find the problem.
You can use -fstack-protector and friends, too.
Good luck,
Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden