Repository navigation
Recursion Crash #82
Description
Activity
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
On Dec 24, 2014, at 9:00 AM, Jamie Wutke notifications@github.com wrote:
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.3Thread : com.apple.main-thread
0x39d3bf9c psynch_mutexwait + 24
0x39da529d _pthread_mutex_lock_contended + 52
0x39da1d3b _pthread_mutex_lock + 262
0x2f5cbd67 -[NSRecursiveLock lock] + 14
0x0014c651 -FICImageTable entryExistsForEntityUUID:sourceImageUUID:
0x001498e9 -FICImageCache _processImage:forEntity:withFormatName:completionBlocksDictionary:
0x001492bf -FICImageCache _imageDidLoad:forURL:
0x2f5eb64f -[NSBlockOperation main] + 130
0x2f5db875 -[__NSOperationInternal _start:] + 772
0x2f67f745 __NSOQSchedule_f + 60
0x39c70d3f _dispatch_client_callout + 22
0x39c736c3 _dispatch_main_queue_callback_4CF + 278
0x2ec71641 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 8
0x2ec6ff0d __CFRunLoopRun + 1308
0x2ebda729 CFRunLoopRunSpecific + 524
0x2ebda50b CFRunLoopRunInMode + 106
0x33b166d3 GSEventRunModal + 138
0x3153b871 UIApplicationMain + 1136
0x000abca7 main (main.m:16)
Thread : Crashed: com.path.FastImageCacheQueue
0x39d62af0 tiny_malloc_from_free_list + 3
0x39d619ed szone_malloc_should_clear + 228
0x39d619ed szone_malloc_should_clear + 228
0x39d64c81 malloc_zone_calloc + 76
0x39d64c23 calloc + 50
0x3978e197 class_createInstance + 42
0x39796c75 _objc_rootAlloc + 32
0x0014d035 -FICImageTable _nextEntryIndex
0x0014d115 -FICImageTable _nextEntryIndex
0x0014d115 -FICImageTable _nextEntryIndex
…
0x0014d115 -FICImageTable _nextEntryIndex
0x0014d115 -FICImageTable _nextEntryIndex
—
Reply to this email directly or view it on GitHub.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
0 CoreFoundation 0x00000001843a5df4 CFBasicHashFindBucket + 952
1 CoreFoundation 0x00000001843b7038 CFBagGetValue + 20
2 CoreFoundation 0x00000001843b7038 CFBagGetValue + 20
3 Foundation 0x00000001852e520c -[NSCountedSet member:] + 80
4 CoreFoundation 0x00000001843b7008 -[NSSet containsObject:] + 28
5 SampleApp2 0x00000001000f3e00 -FICImageTable oldestEvictableEntityUUID
6 SampleApp2 0x00000001000f3c38 -FICImageTable _nextEntryIndex
7 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
8 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
9 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
10 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
11 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
12 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
13 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
14 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
15 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
16 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
17 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
18 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
19 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
20 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
21 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
22 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
23 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
24 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
25 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
26 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
27 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
28 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
29 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
30 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
31 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex
32 SampleApp2 0x00000001000f3c74 -FICImageTable _nextEntryIndex- (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
issue with _inUseEntries having become corrupted or with _MRUEntries. The
fact that _nextEntryIndex is being called recursively repeatedly tells me
that your image table somehow has many more entries than its maximum count.
Do you know the count and the max count when this crash occurs? Any idea
how your table got to be so much bigger than maxCount? That should never
happen...On Mon, Aug 3, 2015 at 10:19 AM, Brian Liang notifications@github.com
wrote:(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 hereNSString *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;
}—
Reply to this email directly or view it on GitHub
#82 (comment).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
wrote: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.
—
Reply to this email directly or view it on GitHub
#82 (comment).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