I'm also getting crashes on that line actually when downloading lots of items in a UITableView

I have also seen a crash on this. I'm on commit ff2b30e, and the crash occured on line 74 of SDWebImageDownloaderOperation.m. See the Crashlytics stack trace for more info.

I see this issue as well. Came type of crash report.

I also see failed downloads which I am now guessing might have to do with this issue.

i might have to abandon this library if this remains an issue. are there
any plans on fixing this?

On Fri, Sep 20, 2013 at 5:51 PM, joshuafeldman notifications@github.comwrote:

I see this issue as well. Came type of crash report.

I also see failed downloads which I am now guessing might have to do with
this issue.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/497#issuecomment-24820183
.

Why couldn't you use scheduleInRunLoop instead of explicitly setting a timeout?

This was to fix a dead thread issue under ios5 (only). Maybe we could add a condition on the OS version, and use a simple CFRunLoopRun for iOS6+.

Wouldn't you need to be executing on a run loop to receive NSURLConnectionDelegate messages safely? Since this is a subclass of NSOperation I believe you need some sort of run loop for the connection layer otherwise the connection messages could be lost.

I actually think this is a fairly large issue. From my understanding an NSURLConnection should almost always be scheduled in a run loop, otherwise it's possible the background thread it is running on can exit before it finishes. I think we would need something along the lines of:

[self.connection scheduleInRunLoop:runLoop forMode:[NSSet setWithObject:NSRunLoopCommonModes]];

I see that you added a conditional for 5.0. I don't believe this is an effective solution for this problem.

You closed this issue but didn't actually fix the problem. iOS 5.0 still suffers from downloads failing. I believe using scheduleInRunLoop will fix this issue as well as the dead thread problems.

I think this issue should be reopened.

start

Causes the connection to begin loading data, if it has not already.

- (void)start

Discussion

Calling this method is necessary only if you create a connection with the initWithRequest:delegate:startImmediately: method and provide NO for the startImmediately parameter. If you don’t schedule the connection in a run loop or an operation queue before calling this method, the connection is scheduled in the current run loop in the default mode.

@joshuafeldman: did you try to manually schedule the connection to see if it fix both issues?

@rs But since you are scheduled in an operation queue wouldn't you need to place it in a run loop? It says if you don't it will be scheduled in the current run loop in the default mode, but you have. Am I wrong?

@rs I haven't I am in the middle of another issue right now, flipping back and forth between Xcode and this discussion :)

The current runloop in the context of an NSOperation is the runloop of the NSOperation's thread. That's exactly what we want, isn't it?

I don't think so. I believe if you don't schedule it in a run loop (when inside an NSOperation) it can exit.

I took a quick peak into AFNetworking's NSOperation subclass and they do indeed follow what I was saying. They also call start after the connection has been scheduled in the run loop.

https://github.com/AFNetworking/AFNetworking/blob/master/AFNetworking/AFURLConnectionOperation.m

If I had some more time right now I would test, but I really do think this is a pretty big issue. I would love to use SDWebImage in the next update in one of my applications but this is a major problem in our QA right now.