SDWebImage: FREQUENT CRASH in [SDWebImageDownloaderOperation cancelInternal]

New Issue Checklist

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

Issue Info

Info	Value
Platform Name	ios
Platform Version	9.0+
SDWebImage Version	4.0.0
Integration Method	cocoapods
Xcode Version	Xcode 8.2.1
Repro rate	30%

Issue Description and Steps

Crashing very frequently after switching to latest release

Crashed: com.apple.main-thread
0  libobjc.A.dylib                0x240fba86 objc_msgSend + 5
1  Foundation                     0x25087a5b +[NSConcreteNotification newTempNotificationWithName:object:userInfo:] + 118
2  Foundation                     0x250879af -[NSNotificationCenter postNotificationName:object:userInfo:] + 46
3  Foundation                     0x2508c4fb -[NSNotificationCenter postNotificationName:object:] + 30
4  SDWebImage                     0x145e87d __47-[SDWebImageDownloaderOperation cancelInternal]_block_invoke (SDWebImageDownloaderOperation.m:207)
5  libdispatch.dylib              0x244c3cbf _dispatch_call_block_and_release + 10
6  libdispatch.dylib              0x244c3cab _dispatch_client_callout + 22
7  libdispatch.dylib              0x244c8559 _dispatch_main_queue_callback_4CF + 1532
8  CoreFoundation                 0x248f3755 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
9  CoreFoundation                 0x248f1c4f __CFRunLoopRun + 1590
10 CoreFoundation                 0x248401c9 CFRunLoopRunSpecific + 516
11 CoreFoundation                 0x2483ffbd CFRunLoopRunInMode + 108
12 GraphicsServices               0x25e5caf9 GSEventRunModal + 160
13 UIKit                          0x28f7a435 UIApplicationMain + 144
14 justunfollow                   0x65339 main (main.m:14)
15 libdispatch.dylib              0x244ec873 (Missing)

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 5
Comments: 29 (3 by maintainers)

Commits related to this issue

Not passing ‘self’ on SDWebImageDownloadStopNotification, to avoid crashes reported at https://github.com/rs/SDWebImage/issues/1807 . — committed to billyto/SDWebImage by billyto 7 years ago
#1807 - #1821 - Fixing incorrectly retained pointer to self which appears to create a dangled pointer — committed to joshuafeldman/SDWebImage by joshuafeldman 7 years ago
#1807 - #1821 - Fixing incorrectly retained pointer to self which appears to create a dangled pointer — committed to Privalia/SDWebImage by joshuafeldman 7 years ago
Merge pull request #1940 from joshuafeldman/master #1807 - #1821 - Fixing incorrectly retained pointer to self which app… — committed to SDWebImage/SDWebImage by bpoplauschi 7 years ago
#1807 - #1821 - Fixing incorrectly retained pointer to self which appears to create a dangled pointer — committed to Lightricks/SDWebImage by joshuafeldman 7 years ago

Most upvoted comments

All joking aside: what’s going on here? Do we need to file a PR to remove the self reference from the notification?

But more importantly: what is the current status for this project? 5 months with a crash like this out there seems like an awful long time

piercifani on Jul 20, 2017

@bpoplauschi Interestingly enough, in summary we have 1000 crashes like this. We’re also getting crashes in random networking foundation places, and none of our code appears in stack traces. Something similar happens in some (but not all) SDWebImage related crashes. Do you think it is just an issue in CFNetwork / Foundation which is just invoked by SDWebImage?

truemetal on Feb 22, 2017

Our baby-bug turned five months just a couple of days ago! 🎉 🎂

675008-a8787d50-7960-4c0c-9876-359a3f85e123

truemetal on Jul 19, 2017

Sorry guys this took so long but I did not have the time to properly investigate. Here are my findings:

the issue is probably caused by f4bdae6 - fixing that issued made this one appear. Basically, we used to make sure we call cancel on the same thread as start which means the exact thread that runs the operation. This behaviour stopped working at some point (probably we changed something in starting operations) so f4bdae6 tried to fix it, so cancelInternal was called again. Now it was not called on the same thread, therefore the threading issue.
#1940 tries to fix the issue by using weak references. Let’s see how that goes. If there are still issues, we can just pass nil, but this fix is better because when the instance exists, we pass it.
I will close the other PR’s and cut a release very soon

bpoplauschi on Jul 28, 2017

I will try to come up with a fix this week. @billyto has a good point. That might be a cause. Any other ideas/suggestions?

bpoplauschi on Mar 3, 2017

@bpoplauschi We are getting same issue. we have 1000 crashes like this. We have a big number of user. So this is very critical for us.

Nishant-goibibo on Feb 28, 2017

issue

Jorc on Jul 20, 2017

I’m not familiar with the code base, but the self looks suspicious in here

https://github.com/rs/SDWebImage/blob/00bf467eb79bb97024eba7393169030a17b98018/SDWebImage/SDWebImageDownloaderOperation.m#L207

Any hints about in what conditions self could be nil?
Would a weakSelf/StongSelf dance in the block fix the issue? but any collateral problems if so?

billyto on Mar 1, 2017