Discrepancies between debug/release profiles when counting items from a plist for numberOfItemsInSection for UICollectionView

Question

I have a UICollectionView whose collectionView:numberOfItemsInSection: is defined as follows:

- (NSInteger)collectionView:(UICollectionView *)collectionView numberOfItemsInSection:(NSInteger)section
{
    return self.contents.count;
}

self.contents is lazily allocated as follows:

- (NSArray *)contents
{
    if (!_contents) {
        _contents = [[XYZSharedMemoryStore sharedStore] clContents];
    }
    return _contents;
}

clContents returns an NSArray, as follows:

- (NSArray *)clContents
{
    NSString *path = [[NSBundle mainBundle] pathForResource:@"cl_contents" ofType:@"plist"];
    NSArray *products = [[NSArray alloc] initWithContentsOfFile:path];
    return products;
}

XYZSharedMemoryStore is a singleton defined as follows:

+ (id)sharedStore
{
    static XYZSharedMemoryStore *sharedStore = nil;
    if (!sharedStore) {
        sharedStore = [[super allocWithZone:NULL] init];
    }
    return sharedStore;
}


+ (id)allocWithZone:(NSZone *)zone
{
    return [self sharedStore];
}


- (id)init
{
    self = [super init];
    if (self) {
        // STUFF
    }
    return self;
}

Going full circle, the problem I'm having is that self.contents.count in collectionView:numberOfItemsInSection: returns 0 when I'm in a release profile and the correct number (10) in debug mode, so in the release profile, my UICollectionView doesn't display any cells. The profiles are in the default state that Xcode creates them in.

Any ideas what might be going on here?

Try to find Optimization Level property in Build Settings for your target and switch it for debug profile to "-Os" (the same as for Release). If the problem will appear in debug mode I guess this is memory related problem. — Artur Ozierański, Jun 13 '13 at 20:49
Ok, that definitely causes the debug profile to behave the same. Memory related, you say? — kid_x, Jun 13 '13 at 20:54
Yes, ARC behaviour could be little bit different for lower optimization level and may not release things properly (in a proper time). Propably count is 0 because self.contents is nil. Please check that with opt level set to -Os in debug and this will give us another clue :) — Artur Ozierański, Jun 13 '13 at 20:58
Yeah, I set it to -Os in debug, from -O0 originally, and the problem happened. Would it be ill-advised to lower the optimization level for the release profile? — kid_x, Jun 13 '13 at 21:00
Still seems a little strange. self.contents, as a getter, should be a blocking call that ends by assigning a value to the _contents ivar ... — kid_x, Jun 13 '13 at 21:02
You were right. I set self.contents as a weak reference, so I guess I made a mistake all along, and the lack of optimization in debug was letting it slip through the cracks. Thanks for your help! — kid_x, Jun 13 '13 at 21:16

score 0 · Accepted Answer · answered Jun 13 '13 at 21:31

So, this was a case of programmer error ...

I was setting my self.contents as a weak reference, so by all rights it should have been deallocated immediately and always returning a count of 0. Since the debug configuration has an optimization level of None [-O0], it wasn't deallocating immediately, allowing me to use it.

The release configuration is set to Fastest, Smallest [-Os], causing the weakly-referenced array to deallocate immediately, not allowing my UICollectionView to pick up its values.

Thanks to Artur Ozierański for his help.

Discrepancies between debug/release profiles when counting items from a plist for numberOfItemsInSection for UICollectionView

1 Answers1