Why does release build fail and not debug?

Question

I have a device/debug build that works fine. When I build for release and distribute onto the device, I get this error:

*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[UILabel setWidth:]: unrecognized selector sent to instance 0x1605a0'

It is occurring in cellForRowAtIndexPath:

cell.videoName.width = 163.0;

where cell is a custom UITableViewCell and videoName is a UILabel. Why would the debug build work fine and release fail? Distribution build also fails. All are set for Base SDK == iPhone OS 3.0.

To get a release build onto the phone, I'm simply changing my code signing to developer. I've also tried the distribution build through iTunes but it fails with the same error.

--- edit ---

I'm loading the cell like this:

static NSString * QuestionCellIdentifier = @"QuestionCellIdentifier";
TopicCellController *cell = (TopicCellController *)[tableView dequeueReusableCellWithIdentifier:QuestionCellIdentifier];

if(cell == nil){
 NSArray *nib = [[NSBundle mainBundle] loadNibNamed:@"TopicCell" owner:self options:nil];
 cell = [nib objectAtIndex:0];
}

cell.videoName.width = 163.0;

At runtime, the cell is of the custom type and videoName isn't nil. If I remove the last line (setting width), it works fine.

--- Edit: new discovery ---

I have found that rather than calling width, I can do this and it works in release:

cell.videoName.frame = CGRectMake(10, 10, 100, 30);

That really doesn't make any sense.

Answer 1

It sounds like you have either got some debug code (tracing with NSLog?) that has side effects, or you have an intermittent race condition between threads that only appears in the faster release build.

So I would check firstly for debug-dependent code and then if you have any background threads check whether they might affect the cell.

It might also be a bug in your cellForRowAtIndexPath reuse identifier processing that results in a nil sometimes - but it is difficult to see why this would only happen in release builds. Without seeing how your custom cell is set up it is difficult to comment more.

Answer 2

In my experience this is usually because allocated memory is initialized to 0x00 in a debug build, and not in a release build. Therefore in the release build one of the members of your data structure has a selector that is leftover from something else. In the debug build it's set to zero.

But I don't know if the iPhone SDK environment initializes memory to zeroes--it seems that more modern development environments in a debug build initialize newly allocated memory to something like 0xcd instead of 0x00.

Also, you might want to check this StackOverflow question.