Re: Bug related to GCC_OPTIMIZATION_LEVEL
Re: Bug related to GCC_OPTIMIZATION_LEVEL
- Subject: Re: Bug related to GCC_OPTIMIZATION_LEVEL
- From: Jason Swain <email@hidden>
- Date: Tue, 1 Jun 2010 16:39:27 +0100
You were right about the uninitialized variable, it was just very difficult to get enough information from the debugger to track the problem down as the end result was quite detached from the initial error. The debug code worked because any value except for 0 caused the correct path to be taken. I've no idea why the optimized version caused that particular variable to be 0 without initialization, but that's what was happening.
Thanks for taking the time to comment, it's always useful for future reference to have a few things to be able to try.
Jason
On 1 Jun 2010, at 16:28, Ken Thomases wrote:
> 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