iOS CATiledLayer crash

Question

I have a pdf reader app for the iPad where I am using a scrollview to display each page. I keep the page in view and one page either side of the page in view. I have seperate views for portrait and landscape views. The portrait view showns a single page and the landscape viewer shows 2 pages.

When the iPad changes orientation I unload the view for the old orientation and load the view for the new orientation. So say it was in portrait view and then changes to landscape the app unloads the portrait view and loads the landscape view. This all works great except when the pdf's are large.

The pdf's are drawn using tiledlayers. The app is scrashing when the orientation is changed with large pdf's. The app only crashes if the orientation is changed before the tiles have all been drawn. My guess is that it is crashing because it is trying to draw tiles to a view than has been unloaded. So is there a way to stop the drawing of tiles when I unload the view?

I did not find proper solution for this but workaround prevented crashes. Ended up putting if (self.tiling == YES && [self.view superview] != nil) into - (void)drawLayer:(CALayer *)layer inContext:(CGContextRef)ctx method. Self tiling is set before view is removed from superview or in your case, before orientation change. You can avoid this problem by having one view for all orientations. My workaround prevented crashes but didn't prevent CATiledLayer from accessing image or holding lock on image some mysterious way. End result was inability to delete said image from file system. Good luck! — TheBlack, May 16 '11 at 12:33

score 5 · Accepted Answer · edited Dec 26 '13 at 17:04

5

You need to set CALayer's delegate to nil, then remove it from the superview. This stops rendering, afterwards you can safely dealloc.

- (void)stopTiledRenderingAndRemoveFromSuperlayer; {
    ((CATiledLayer *)[self layer]).delegate = nil;    
    [self removeFromSuperview];
    [self.layer removeFromSuperlayer];
}

Also, make sure to call this from the main thread, or else horrible bugs will await you.

edited Dec 26 '13 at 17:04

Andrew Barber

39,603
20
94
123

answered Aug 01 '11 at 23:44

steipete

7,581
5
47
81

1) Are you sure `[self.layer removeFromSuperlayer];` is required? 2) Doesn't the fact that your retain/release helps against crashes points to the fact that you have a race condition which can still happen? Retaining protects against `dealloc` being called (as result of release on another thread), but the dealloc can still occur between the start of the function to the call to retain, and you will end up calling retain on deallocated memory. – Danra Nov 14 '11 at 16:53
1

I also found that you must also remove any subviews *before* setting self.layer.delegate nil, otherwise they will not be deallocated. – Danra Nov 14 '11 at 16:58
You're correct, the retain/release is not needed - i updated my answer. – steipete Nov 15 '11 at 12:18
1

You, sir, are beautiful (not to mention the beauty of `PSPDFKit` as well =P). – fumoboy007 Apr 02 '13 at 17:37

score 3 · Answer 2 · answered Dec 01 '14 at 20:10

I haven't looked at the disassembly to see, but we are using a slightly different solution. Setting the CATiledLayer.content property to nil blocks and forces all queued render blocks to complete. That can safely be kicked off to a background thread, then releasing the UIView can be kicked back to the main thread to let the view and layer dealloc.

Here's one example of a UIViewController dealloc implementation that will keep your CATiledLayer owning view alive long enough to safely stop rendering, without blocking the main thread.

- (void)dealloc
{
    // This works around a bug where the CATiledLayer background drawing 
    // delegate may still have dispatched blocks awaiting rendering after
    // the view hierarchy is dead, causing a message to a zombie object.
    // We'll hold on to tiledView, flush the dispatch queue, 
    // then let go of fastViewer.
    MyTiledView *tiledView = self.tiledView;
    if(tiledView) {
        dispatch_background(^{
            // This blocks while CATiledLayer flushes out its queued render blocks.
            tiledView.layer.contents = nil;

            dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.01 * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
                // Make sure tiledView survives until now.
                tiledView.layer.delegate = nil;
            });
        });
    }
}

This is a guess, but some of Apple's frameworks/classes (StoreKit, CATiledLayer, UIGestureRecognizer) claim to have @property (weak) id delegate implementations but clearly do not properly handle the weak delegate. Looking at some disassembly and they are doing decidedly race-bound if != nil checks then touching the weak property directly. The proper way is to declare a __strong Type *delegate = self.delegate, which will either succeed and give you a strong reference guaranteed to survive, or be nil, but it certainly won't give you a reference to a zombie object (my guess is that framework code has not been upgraded to ARC).

Under the hood, CATiledLayer creates a dispatch queue to do the background rendering and appears to either touch the delegate property in an unsafe way or it obtains a local reference but without making it a strong one. Either way, the dispatched render blocks will happily message a zombie object if the delegate gets deallocated. Just clearing the delegate is insufficient - it will reduce the number of crashes but does not safely eliminate them.

Setting the content = nil does a dispatch_wait and blocks until all the existing queued render blocks are finished. We bounce back to the main thread to make sure the dealloc is safe.

If anyone has suggestions for improvement please let me know.

iOS CATiledLayer crash

2 Answers2

Linked