Question

I have a code that compile without problems. It runs well on the iPhone simulator, but on my device, I get an EXC_BAD_ACCESS.

This happens in a helper function to draw gradient. I followed this tutorial to do it. The code I have is as follows:

- (void) drawRect:(CGRect)rect
{
    CGContextRef context = UIGraphicsGetCurrentContext();
    CGColorRef whiteColor = [UIColor whiteColor].CGColor;
    CGColorRef lightGrayColor = [UIColor colorWithRed:230.0/255.0
                                                green:230.0/255.0 
                                                 blue:230.0/255.0 
                                                alpha:1.0].CGColor;
    CGColorRef separatorColor = [UIColor colorWithRed:208.0/255.0
                                                green:208.0/255.0 
                                                 blue:208.0/255.0
                                                alpha:1.0].CGColor;
    CGRect paperRect = self.bounds;
    CGRect nameRect = self.nameLabel.frame;
    CGPoint sepStartPoint = CGPointMake(nameRect.origin.x, 
                                        nameRect.origin.x + nameRect.size.height + 2);
    CGPoint sepEndPoint = CGPointMake(nameRect.origin.x + nameRect.size.width, 
                                      nameRect.origin.x + nameRect.size.height + 2);

    drawLinearGradient(context, paperRect, lightGrayColor, whiteColor);
    draw1PxStroke(context, sepStartPoint, sepEndPoint, separatorColor);

}


// Callee, where the problem is
void drawLinearGradient(CGContextRef context,
                        CGRect rect,
                        CGColorRef startColor, 
                        CGColorRef endColor)
{
    CGColorSpaceRef colorSpace = CGColorSpaceCreateDeviceRGB();
    CGFloat locations[] = { 0.0, 1.0 };

    NSArray *colors = [NSArray arrayWithObjects:
                       (__bridge id)startColor,
                       (__bridge id)endColor,
                       nil]; // Here is the line

    CGGradientRef gradient = CGGradientCreateWithColors(colorSpace, 
                                                        (__bridge CFArrayRef) colors, locations);

    CGPoint startPoint = CGPointMake(CGRectGetMidX(rect), CGRectGetMinY(rect));
    CGPoint endPoint = CGPointMake(CGRectGetMidX(rect), CGRectGetMaxY(rect));

    CGContextSaveGState(context);
    CGContextAddRect(context, rect);
    CGContextClip(context);
    CGContextDrawLinearGradient(context, gradient, startPoint, endPoint, 0);
    CGContextRestoreGState(context);

    CGGradientRelease(gradient);
    CGColorSpaceRelease(colorSpace);
}

Xcode highlights line 12 (the one with nil]; as the error line.

For Peter Hosey, here’s the debugger output:

(gdb) po startColor
<CGColor 0x1deca0> [<CGColorSpace 0x1d3280> (kCGColorSpaceDeviceGray)] ( 1 1 )
Current language:  auto; currently objective-c
(gdb) po endColor
<CGColorSpace 0x1bf120> (kCGColorSpaceDeviceRGB)
(gbd)

My simulator (and iPhone) runs on iOS 5.

What could be causing this crash?

Answer 1

One way to work around this would be to pass UIColors into your function, instead of CGColorRefs, and use an (id)[color1 CGColor] cast for each element of your colors array. This appears to be the most popular way that people are addressing this problem right now.

I point out one use of this in this answer, and there’s extended discussion about this in this Apple developer forum thread. If you use a UIColor’s -CGColor method at the point of declaring your NSArray, and cast to id, everything’s bridged automatically for you. As gparker states in the above-linked forum thread:

The automatic case described by the documentation applies only to
calling an Objective-C method that returns a CF type and then
immediately casting the result to an Objective-C object type. If you
do anything else with the method result, such as assign it to a
variable of a CF type, then it is no longer automatic.

As hatfinch points out, this could mean that your CGColorRefs placed in temporary variables won’t hang around after the last time you reference your UIColors, unless you explicitly retain them. Like the others in that forum thread, I mistakenly thought this was a bug in the bridging implementation, but I can see that I was reading this wrong.