Recursion Crash #82
Comments
|
Can you save the FIC data from a user who has hit this bug and then send it to me? I'd be happy to debug. Sent from my iPhone
|
|
Hey, sorry for the delay in answering. I'll see if I am able to get that info for you. |
|
Any luck? We are seeing this very often. |
|
@mallorypaine Sorry, I haven't been able to get a hold of user data for this. We haven't run into this issue lately. It was happening when our project was in earlier stages of development, so my only thought is that other crashes in the view controller were causing the image cache to become corrupted. |
|
@mallorypaine I don't have a sample app that can reproduce this consistently but for whatever it's worth: Thread : Crashed: com.path.FastImageCacheQueue |
- (NSInteger)_nextEntryIndex {
NSMutableIndexSet *unoccupiedIndexes = [[NSMutableIndexSet alloc] initWithIndexesInRange:NSMakeRange(0, _entryCount)];
[unoccupiedIndexes removeIndexes:_occupiedIndexes];
NSInteger index = [unoccupiedIndexes firstIndex];
if (index == NSNotFound) {
index = _entryCount;
}
if (index >= [self _maximumCount] && [_MRUEntries count]) {
// Evict the oldest/least-recently accessed entry here
NSString *oldestEvictableEntityUUID = [self oldestEvictableEntityUUID];
if (oldestEvictableEntityUUID) {
[self deleteEntryForEntityUUID:oldestEvictableEntityUUID];
index = [self _nextEntryIndex]; // ----- Line 587
}
}
if (index >= [self _maximumCount]) {
NSString *message = [NSString stringWithFormat:@"FICImageTable - unable to evict entry from table '%@' to make room. New index %ld, desired max %d", [_imageFormat name], (long)index, [self _maximumCount]];
[self.imageCache _logMessage:message];
}
return index;
}
|
|
This isn't a recursion crash per se. It appears that there's either an On Mon, Aug 3, 2015 at 10:19 AM, Brian Liang notifications@github.com
|
|
The maximum limit is set to 50 during the cache. This could be related actually, but when I attempt to delete an image from the image table, it actually doesn't delete. The image table data actually grows up to 200+ MB and there's no way to control it. I wonder if this was an issue that was fixed recently? We're on a version of FIC from a year ago. |
|
What is the most recent FIC commit in your version of FIC? On Tue, Aug 4, 2015 at 10:54 AM, Brian Liang notifications@github.com
|
|
Pretty embarrassing on our part but we actually don't know. (didn't fork, we just imported the source) All I know is that we got the latest from Master sometime before March 7, 2014... Which means after 1.2 and before 1.3 as it looks like. I can provide the zip of our version of FICImageCache if that helps. I tried to go through a few diffs to see how far off we are from 1.3 and doesn't seem like much has changed so we can assume 1.3. Appreciate the help, let me know if there are more info you need. |
This is something that has appeared in crash logs. Unfortunately, I don't know how to reproduce it. The worst part about this crash is that once it happens, it will happen every time the user enters the view controller that uses FastImageCache.
Version:
FastImageCache 1.3
The text was updated successfully, but these errors were encountered: