CATiledLayer crashes when drawing previously prepared CGPath

Question

I am using CATiledLayer as backing layer for my UIView, which I have put inside UIScrollView. In init method of my view I am creating CGPathRef object which draws simple line. When I am trying to draw this path inside drawLayer:inContext it occasionally crashes with EXEC_BAD_ACCESS (rarely) when I am scrolling / zooming.

The code is very simple, I am using only standard CG* functions:

- (id)initWithFrame:(CGRect)frame
{
    self = [super initWithFrame:frame];
    if (self) {
        CATiledLayer *tiledLayer = (CATiledLayer *)[self layer];
        tiledLayer.levelsOfDetail = 10;
        tiledLayer.levelsOfDetailBias = 5;
        tiledLayer.tileSize = CGSizeMake(512.0, 512.0);

        CGMutablePathRef mutablePath = CGPathCreateMutable();
        CGPathMoveToPoint(mutablePath, nil, 0, 0);
        CGPathAddLineToPoint(mutablePath, nil, 700, 700);
        path = CGPathCreateCopy(mutablePath);
        CGPathRelease(mutablePath);
    }
    return self;
}

+ (Class) layerClass {
    return [CATiledLayer class];
}

- (void) drawRect:(CGRect)rect {
}

- (void) drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx {
    CGContextSetRGBFillColor(ctx, 1, 1, 1, 1);
    CGContextFillRect(ctx, self.bounds);

    CGContextSetLineWidth(ctx, 5);

    CGContextAddPath(ctx, path);
    CGContextDrawPath(ctx, kCGPathStroke);
}

- (void)dealloc {
    [super dealloc];
}

UPDATE: I have noiced that this problem exists only on iOS 5, it works fine on 4.3

debugging an EXEC_BAD_ACCESS is easy when you turn on NSZombieEnabled, it will then show you which deallocated variable is being called. — Wolfert, Dec 16 '11 at 12:03
but in this code it is not possible to do something bad with memory, anyway it happens only with CATiledLayer and multiple threads. — Piotr Wach, Dec 16 '11 at 13:04
Is this a class shared by the threads or does every thread has its own instance? — Wolfert, Dec 16 '11 at 15:38
The view is created in UI thread, but drawayer method is invoked from different threads, as it is used by CATiledLayer, and that is the way that it works. BAD_ACCESS always appears on this line: CGContextAddPath(ctx, path) — Piotr Wach, Jan 04 '12 at 10:33

Nick Baicoianu · Accepted Answer · 2012-03-09T21:53:05.217

I ran into a similar issue when attempting to draw cached CGPath objects on a custom MKOverlayView.

The crash may occur because a CGPath can't be simultaneously drawn on multiple threads – it's an opaque class which (as specified in the documentation) contains a pointer to the current point in its points array. Two or more threads iterating over this array simultaneously while they draw it could lead to undefined behavior and a crash.

I worked around this by copying the CGPath object into each drawing thread (contained within a mutex lock to prevent incomplete copying):

//lock the object's cached data
pthread_mutex_lock(&cachedPathMutex);
//get a handle on the previously-generated CGPath (myObject exists on the main thread)
CGPathRef myPath = CGPathCreateCopy(myObject.cachedPath);
//unlock the mutex once the copy finishes
pthread_mutex_unlock(&cachedPathMutex);

// all drawing code here
CGContextAddPath(context, myPath);
...
...
CGPathRelease(myPath);

If you're concerned about the memory overhead of doing a copy on each thread, you can also work directly on the cached CGPath objects, but the mutex will have to remain locked during the whole drawing process (which kind of defeats the purpose of threaded drawing):

//lock the object's cached data
pthread_mutex_lock(&cachedPathMutex);

//get a handle on the previously-generated CGPath (myObject exists on the main thread)
CGPathRef myPath = myObject.cachedPath;

// draw the path in the current context
CGContextAddPath(context, myPath);
...
...

//and unlock the mutex
pthread_mutex_unlock(&cachedPathMutex);

I'll qualify my answer by saying that I'm not an expert on multithreaded drawing with Quartz, only that this approach solved the crashes in my scenario. Good luck!

UPDATE: I revisited this code now that iOS 5.1.0 is out and it looks like the root cause of the issue may have actually been a bug in Quartz in iOS 5.0.x. When testing on iOS 5.1.0 with the CGPathCreateCopy() and mutex calls removed, I'm seeing none of the crashes experienced on iOS 5.0.x.

//get a handle on the previously-generated CGPath (myObject exists on the main thread)
CGPathRef myPath = myObject.cachedPath;

// all drawing code here
CGContextAddPath(context, myPath);
...
...
//drawing finished

Since chances are we'll be supporting iOS 5.0.x for a while, it won't hurt to keep the mutex in your code (other than a slight performance hit), or simply run a version check before drawing.

Thanks for this - it fixed a similar issue with my custom MKOverlayView. If my reading of the Concurrency Programming Guide is correct, it might be slightly more efficient to use a GCD-style dispatch_synch against a serial queue instead of using the mutex. Shame about having to create the copies of the paths - I guess the question is whether creating the copies in a serial queue or within a lock is faster than recreating the paths from scratch every time. The answer depends on the complexity/efficiency of the path creation code, I suppose. — stephent, Feb 06 '12 at 01:23

CATiledLayer crashes when drawing previously prepared CGPath

1 Answers1