I’m proud to say that all of my apps are pretty solid. They rarely crash. At least, I assume they rarely crash, because I very rarely receive crash reports from users. When I do, it’s usually from beta testers before the application has been shared with the general public.

But after Apple released 10.4.11, I started receiving crash reports at an accelerated pace. The log is the same in every instance, and culminates in what appears to be a threaded NSURLConnection caching operation:

Now it so happens that WebKit is the one crashing in many of these cases, but I suspect the problem is more widespread than that. In any case, the problem is definitely more widespread than just MarsEdit. Searching Google reveals a number of similar results, from a variety of applications, including Apple’s own.

If you’re a developer and your application uses WebKit or NSURLConnection, chances are you’ve noticed an increase in crash reports, too. Always on 10.4.11, always involving NSURLConnection. If you’re a user running 10.4.11, chances are you’ve noticed that network-enabled applications seem to be a bit more flakey and crash-prone.

The fact that the bug seems to be fixed in Leopard makes me think that this is a bug whose source was identified and fixed. Now the question is, will Apple ever ship a 10.4.12 containing a fix? Or will those users be stuck in crash-ville forever?

Apple needs to get this fixed. For these poor 10.4.11 users who got stuck with a buggy URL loader, and for us poor developers who have to gently explain to them that it’s out of our control. I have to assume there’s already a bug reported against this, but better safe than sorry, I wrote up another one: Radar #5704773.

So why I am I writing this blog entry? Because I want other developers who read my blog or who find it by Google search to know that they’re not crazy. And I want users who run into this crash to please remember to send the crash report to Apple. They need to know that this is a serious issue that is impacting you and the apps you use.

25 Responses to “NSURLConnection Crashing Epidemic”

I noticed a dramatic change in the stability of my daily work when I “upgraded” to 10.4.11. I couldn’t ever put a finger on why I was getting crashes, but this could very well be it. I’ve since jumped to Leopard, so I can’t confirm anything, but this was a real PITA in my daily usage.

NSURLConnection and 10.4 has never been a happy combination in my experience. Recently I found that (on Tiger) POST-ing data essentially seems to leak all uploaded data. This presented a problem as I was uploading GBs of data… After some investigation it turned out that the leak occurs when the url loading system caches the server response for each URLRequest (the call tree indicated that the memory leak happens when a hash value is calculated from the URLRequest). Luckily I didn’t need response caching in the first place, so I turned it off and the leaking stopped.

This also seems to be fixed in 10.5 but it would be nice if it ‘just worked’ on 10.4 too. Maybe it could be part of a Safari update?

This is a problem in 10.5.1 too. Almost every time anything tries to access the web through our ISA server – which requires authentication – a crash occurs. I’ve had to switch to Camino from Safari, and also to avoid HTML emails. I don’t think it happened so much in 10.5.

I think NSURLConnection is known to have crashing issues with authenticated proxies. Different crash, surely, but NSURLConnection related – and not fixed in Leopard.

Patrick, I’m curious that you’re uploading that much data with NSURLConnection. I found it to be entirely unsuited to large quantities of POST data and had to switch to CFNetwork. For one, I couldn’t see any way to stream data to it, so I’d have to load the entire file into memory. And since there are no hooks for uploading, the whole program beachballs while the upload is in progress. If you’ve solved these issues without punting on NSURLConnection entirely, I’d be very interested in discussing your solution.

I’ve experienced a number of Safari crashes on my own system and received a number of Vienna crash reports with the signature -[NSURLConnection(NSURLConnectionInternal) _didFinishReturnCachedResponse:], all of which are from Mac OS X 10.4.11.
For what it’s worth, I’ve seen a number of Vienna crash reports with NSURLConnection on Mac OS X 10.5, but they have a different signature.

@Christopher Masto
NSURLConnection does async loading and has a delegate. I use a custom ‘loader’ class to handle all delegate callbacks, which is convenient. While this loader does its work, you can just run the runloop until it’s done.

You can stream data by setting an instance of NSInputStream using NSMutableURLRequests setHTTPBodyStream: method. Note that you cannot subclass NSInputStream to do fancier stuff: subclassing NSInputStream is broken! (on both 10.4 and 10.5)

I have been seeing crashes while using Webkit apps, in particular Mail very often, then also NetNewsWire and less frequently. And I am running 10.5.1. This seems to be consistent with observations from others in this thread. Or it is just a coincidence, and red-sweater is so popular that it brings enough traffic to make it look like a pattern ;-)

So that explains why I’ve been getting crashes in MarsEdit and Safari! Prior to 10.4.11 I was using a Macbook and sometime around late September I ugraded to a MBP. For the past several months I just though for some reason my MBP was less stable than my previous Macbook. This makes the upgrade to Leopard I planned for this weekend all the more worth while.

The developer of del.icio.us client Pukka has also documented this problem on his blog.

Tom beat me to it, but yes, I’ve seen some pretty regular crashing plaguing Leopard users (10.5 and 10.5.1) but nothing on Tiger yet. Mine is related to authentication over HTTPS and/or proxy servers. You can see this happening in Safari as well:

Dude! Never mind, I think they got it in the security update AND they credited you!

Foundation

CVE-ID: CVE-2008-0058

Available for: Mac OS X v10.4.11, Mac OS X Server v10.4.11

Impact: Visiting a maliciously crafted website may lead to a denial of service or arbitrary code execution

Description: A thread race condition exists in NSURLConnection’s cache management, which can cause a deallocated object to receive messages. Triggering this issue may lead to a denial of service, or arbitrary code execution with the privileges of Safari or another program using NSURLConnection. This update addresses the issue by removing an unsynchronized caching operation. This issue does not affect systems running Mac OS X v10.5 or later. Credit to Daniel Jalkut of Red Sweater Software for reporting this issue.

I’m having severe Safari crashes when behind an authenticating proxy. When on a network where the proxy isn’t in play, Safari is much more reliable. Behind the proxy, I can trigger repeatable crashes just by visiting store.apple.com.

Thanks neuroklinik – but I believe the crash you’re seeing is separate from this one that I reported. I’ve heard from others that there are specifically crashes having to do with proxy servers and NSURLConnection, which it sounds like you’re running into.