Sdwebimage: Crash on [SDWebImageDownloaderOperation reset]_block_invoke

[EugeneEl]

[X] I have read and understood the CONTRIBUTING guide
[X] I have read the Documentation
[X] I have searched for a similar issue in the project and found none

I got this crash twice. Unfortunately cannot reproduce it.
Just can provide info from Fabric.

Issue Info

Info | Value |
-------------------------|-------------------------------------|
Platform Name | iOS
Platform Version | 10.3.1
SDWebImage Version | 4.0.0
Integration Method | Cocoapods
Xcode Version | Xcode 8.0
Repro rate | twice
Repro with demo prj | cannot reproduce
Demo project link | cannot reproduce

Issue Description and Steps

Crashed: com.hackemist.SDWebImageDownloaderOperationBarrierQueue
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x000000092a29beb8

0 libobjc.A.dylib 0x184424150 objc_msgSend + 16
1 SDWebImage 0x1013d31e0 __38-[SDWebImageDownloaderOperation reset]_block_invoke (SDWebImageDownloaderOperation.m:227)
2 libdispatch.dylib 0x1848669e0 _dispatch_call_block_and_release + 24
3 libdispatch.dylib 0x1848669a0 _dispatch_client_callout + 16
4 libdispatch.dylib 0x184878578 _dispatch_queue_concurrent_drain + 1372
5 libdispatch.dylib 0x18486a2d4 _dispatch_queue_invoke + 892
6 libdispatch.dylib 0x184876a50 _dispatch_root_queue_drain + 540
7 libdispatch.dylib 0x1848767d0 _dispatch_worker_thread3 + 124
8 libsystem_pthread.dylib 0x184a6f1d0 _pthread_wqthread + 1096
9 libsystem_pthread.dylib 0x184a6ed7c start_wqthread + 4

Also downloaded crashreport from Apple

- (void)reset {
    dispatch_barrier_async(self.barrierQueue, ^{
        [self.callbackBlocks removeAllObjects]; // crash is here
    });
    self.dataTask = nil;
    self.imageData = nil;
    if (self.ownedSession) {
        [self.ownedSession invalidateAndCancel];
        self.ownedSession = nil;
    }
}

[bpoplauschi]

This is very strange, will look into it.

[ChristianPraiss]

Also experiencing this issue!

[huipengo]

We are facing same issue. I used v4.0

[yukitoto]

Also facing this issue.

[Achilles1988]

I come a cross to this issue in pressure test frequently

[JordanMcCulloch]

Same issue here! Caught using Fabric.io Crashlytics during a user session.

Issue Info:

• Platform Name: iOS
• Platform Version: 10.3.1 (14E304)
• SDWebImage Version: 4.0.0
• SDWebImage/Core: 4.0.0
• Integration Method: Cocoapods
• Device Version: iPad Mini 2
• Repro rate: Once so far (just pushed to TestFlight last night).
• Repro: Caused when scrolling fast through a table of images. Each table cell's image is retrieved from the cloud and saved into mem via SDWebImage when the cell is loaded.

Methods used in tableView 'cellForRowAt':

1. SDImageCache.shared().imageFromMemoryCache() // First try to get from RAM.
2. SDImageCache.shared().queryCacheOperation() // Then try to get from Disk.
3. SDWebImageDownloader.shared().downloadImage() // Finally download from cloud.

---

Thread #0:

Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x00000004bbcbbeb8

0 libobjc.A.dylib 0x181a78150 objc_msgSend + 16
1 Foundation 0x1839f29c8 +[NSConcreteNotification newTempNotificationWithName:object:userInfo:] + 132
2 Foundation 0x1839f2904 -[NSNotificationCenter postNotificationName:object:userInfo:] + 40
3 SDWebImage 0x100b5b2ec __47-[SDWebImageDownloaderOperation cancelInternal]_block_invoke + 72
4 libdispatch.dylib 0x181eba9e0 _dispatch_call_block_and_release + 24
5 libdispatch.dylib 0x181eba9a0 _dispatch_client_callout + 16
6 libdispatch.dylib 0x181ebf5e8 _dispatch_main_queue_callback_4CF + 996
7 CoreFoundation 0x182fb10c0 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
8 CoreFoundation 0x182faecdc __CFRunLoopRun + 1572
9 CoreFoundation 0x182eded94 CFRunLoopRunSpecific + 424
10 GraphicsServices 0x184948074 GSEventRunModal + 100
11 UIKit 0x189190130 UIApplicationMain + 208
12 AppName 0x100048900 main (AppDelegate.swift:18)
13 libdyld.dylib 0x181eed59c start + 4

---

Thread #9:

com.apple.NSURLConnectionLoader

0 libsystem_kernel.dylib 0x181fdf224 mach_msg_trap + 8
1 libsystem_kernel.dylib 0x181fdf09c mach_msg + 72
2 CoreFoundation 0x182fb0e88 __CFRunLoopServiceMachPort + 192
3 CoreFoundation 0x182faeadc __CFRunLoopRun + 1060
4 CoreFoundation 0x182eded94 CFRunLoopRunSpecific + 424
5 CFNetwork 0x1836eaca4 +[NSURLConnection(Loader) _resourceLoadLoop:] + 404
6 Foundation 0x183af62c8 __NSThread__start__ + 996
7 libsystem_pthread.dylib 0x1820c575c _pthread_body + 240
8 libsystem_pthread.dylib 0x1820c566c _pthread_body + 282
9 libsystem_pthread.dylib 0x1820c2d84 thread_start + 4

[hei9gag]

We also facing the same issue and the crash only happens in iOS 10 devices.

[Cooriyou]

I used v4.0 facing same issue.

[gujinku]

Do we have solution for this crash issue please?

[joshuafeldman]

👀 We have it also

[bpoplauschi]

Should be fixed by #1940 - closing for now

[lauramejiaarroyave]

When will be released the 4.1.0 with the fix?

[bpoplauschi]

@lauramejiaarroyave 4.1.0 was just released.

[piercifani]

@bpoplauschi I'm still seeing this crash after the changes in #1940 are applied.

Looking at the code in reset, shouldn't the block dispatched to dispatch_barrier_async be retaining a weak self?

[bpoplauschi]

@piercifani the problem is multiple crashes being almost randomly added to tickets :) so you're referring to the one at the top of this thread described by @EugeneGoloboyar. Indeed that can still happen. I will reopen this ticket and look for a fix.

[bpoplauschi]

@piercifani we can try to use a weakSelf reference in this case because the crash does look like a message sent to deallocated instance. Do you have any other info that might help us? Like a link to Crashlytics or whatever crash reporting tool you use? Frequency? OS versions ...

[piercifani]

Here's the full stack trace out of Crashlytics (I redacted some info, off course)

com.hostapp.hostapp_issue_1165_crash_567b2d42fcb145f18709320b204a6a47_4fce22b77c1b11e784ae56847afe9799_0_v2.txt

It appears to be happening a lot more on iOS 10 than iOS 9 (99% vs 1%), Only 24% when "App In Focus" and all devices are experiencing this issue.

[bpoplauschi]

Thanks for the info @piercifani - it appears you are correct, we need a weak reference there. Probably a race-condition because otherwise I cannot explain how a strong reference to an object can lead to a "message sent to deallocated instance" crash.

[bpoplauschi]

@piercifani I made a commit 2f892f9 with the solution we talked about. Can you try it before we release 4.1.1 - this can take a few more days.

[piercifani]

Thanks! I'll try this on my next release and let you know what I find

[piercifani]

I can confirm that this made the crash disappear on Fabric/Crashlytics so I think it's safe to merge

[piercifani]

Can we assign this to the 4.1.1 release and merge it?

[dreampiggy]

@piercifani The commit 2f892f9 has already in the master branch. So when the 4.1.1 release, it will be right there.

[VidhyaJain]

Hi, I am facing the same crash issue in 4.1.0 release. When will be 4.1.1 available with this fix? I want to submit my app to app store.

[bpoplauschi]

@VidhyaJain we will release in a couple of days - sorry for the delay

[bpoplauschi]

4.1.1 is now released.

[VidhyaJain]

@bpoplauschi :Thanks for release

[dreampiggy]

@VidhyaJain Please use 4.1.2 patch version instead of 4.1.1. We forgot a bug in 4.1.1 and fixed in 4.1.2(only contains fix and no extra feature changes)

[VidhyaJain]

@dreampiggy Thanks! Will take 4.1.2