Crash on -[PINDiskCache objectForKey:fileURL:]

[rex-remind101]

Our crash reporting consistently logs crashes on -[PINDiskCache objectForKey:fileURL:]. This is one of our highest reported crashes. This is on version 2.1.

Stack traces for the queue the crash occurs on look like the following:

Thread : Crashed: com.pinterest.PINDiskCache Asynchronous Queue
0  Foundation                     0x269dea08 -[NSKeyedUnarchiver initForReadingWithData:] + 439
1  Foundation                     0x269de991 -[NSKeyedUnarchiver initForReadingWithData:] + 320
2  Foundation                     0x26a37305 +[NSKeyedUnarchiver unarchiveObjectWithFile:] + 124
3  Remind101                      0x37159f -[PINDiskCache objectForKey:fileURL:] (PINDiskCache.m:605)
4  Remind101                      0x3707e1 __35-[PINDiskCache objectForKey:block:]_block_invoke (PINDiskCache.m:433)
5  libdispatch.dylib              0x25dbdb5b _dispatch_call_block_and_release + 10
6  libdispatch.dylib              0x25dc8365 _dispatch_async_redirect_invoke$VARIANT$mp + 1360
7  libdispatch.dylib              0x25dcc921 _dispatch_root_queue_drain + 1560
8  libdispatch.dylib              0x25dcc305 _dispatch_worker_thread3 + 96
9  libsystem_pthread.dylib        0x25f7bb29 _pthread_wqthread + 1024
10 libsystem_pthread.dylib        0x25f7b718 start_wqthread + 8

All other threads are idle and the main thread is simply spinning the runloop when this happens:

Thread : com.apple.main-thread
0  libsystem_kernel.dylib         0x25ec4c24 mach_msg_trap + 20
1  libsystem_kernel.dylib         0x25ec4a29 mach_msg + 40
2  CoreFoundation                 0x26207355 __CFRunLoopServiceMachPort + 136
3  CoreFoundation                 0x262056dd __CFRunLoopRun + 1036
4  CoreFoundation                 0x26158bf9 CFRunLoopRunSpecific + 520
5  CoreFoundation                 0x261589e5 CFRunLoopRunInMode + 108
6  GraphicsServices               0x273a4ac9 GSEventRunModal + 160
7  UIKit                          0x2a3e8ba1 UIApplicationMain + 144
8  Remind101                      0x241703 main (main.m:16)
9  libdispatch.dylib              0x25e07873 (Missing)

There happen to be quite a large number of queues for PINDiskCache when this occurs though. Their threads look like so:

Thread : com.pinterest.PINDiskCache Asynchronous Queue
0  libsystem_kernel.dylib         0x25ec4c74 semaphore_wait_trap + 8
1  libdispatch.dylib              0x25dcec83 _dispatch_semaphore_wait_slow + 190
2  Remind101                      0x3714b1 -[PINDiskCache objectForKey:fileURL:] (PINDiskCache.m:599)
3  Remind101                      0x3707e1 __35-[PINDiskCache objectForKey:block:]_block_invoke (PINDiskCache.m:433)
4  libdispatch.dylib              0x25dbdb5b _dispatch_call_block_and_release + 10
5  libdispatch.dylib              0x25dc8365 _dispatch_async_redirect_invoke$VARIANT$mp + 1360
6  libdispatch.dylib              0x25dcc921 _dispatch_root_queue_drain + 1560
7  libdispatch.dylib              0x25dcc305 _dispatch_worker_thread3 + 96
8  libsystem_pthread.dylib        0x25f7bb29 _pthread_wqthread + 1024
9  libsystem_pthread.dylib        0x25f7b718 start_wqthread + 8

[garrettmoon]

@rex-remind101 Looks like one of the objects on disk isn't unarchiving correctly. This could be due to a bad implementation of initWithCoder (or secure coder), or it could be due to a file which doesn't support coding getting put in the cache directory (this is less likely). Either way, it doesn't appear to be a bug in PINDiskCache

[rex-remind101]

Since all of our file storage goes through your API wouldn't this be an issue with your library, and therefore not worth just closing? This explanation is a good lead but doesn't necessarily solve anything.

[garrettmoon]

Hey @rex-remind101 I'm happy to reopen the issue with a help wanted tag for a bit!

[rex-remind101]

Great! Thank you :)

[binchensjtu]

@rex-remind101 Have you resolved this crash issue? I also found hight rate crash the same with yours.

[rex-remind101]

Yup, still seeing it on v 2.2.2.

[garrettmoon]

@rex-remind101 @binchensjtu can either of you reproduce the issue?

[garrettmoon]

Going to close this, lemme know if either of you can reproduce the issue.