NSURLConnection Crashing Epidemic

January 24th, 2008

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:

-[NSHTTPURLProtocol startLoading]

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”

  1. razmaspaz Says:

    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.

  2. Patrick Says:

    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?

  3. Rich Says:

    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.

  4. Daniel Jalkut Says:

    Rich: You’re sure it’s the same crash? I have yet to see a single report with this crashlog that came from anything but 10.4.11.

  5. Christopher Masto Says:

    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.

  6. Jesse Says:

    MarsEdit did crash for me on 10.4.11 (cheers auto-save!), but hasn’t flaked under Leopard yet. Hope Apple fixes this for users who can’t upgrade…

  7. Jeff Johnson Says:

    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.

  8. Jussi Says:

    I am seeing many crashers having common denominator of:

    [NSURLConnection(NSURLConnectionReallyInternal) _resourceLoadLoop:]

    The actual crashing point varies somewhat, being sometimes inside com.apple.security and sometimes in Core Foundation.

    The crashes happen mostly in 10.5.1, both on PPC and Intel. I have not analyzed the crashers properly yet though, maybe I’m doing something wrong myself.

  9. Tom Says:

    I’m also seeing this problem in Leopard with NSURLConnection, in my case I’m behind a proxy.

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

    Incredibly irritating – I do wonder if Apple actually test their software sometimes…

  10. Patrick Says:

    @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)

  11. charles Says:

    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 ;-)

  12. Kevin Says:

    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.

  13. ExitToShell Says:

    Sounds like this bug is the Son of the problem Wil Shipley found: http://wilshipley.com/blog/2006/03/pimp-my-code-part-8-mary-mary-why-you.html

  14. Dan York Says:


    It’s because of posts like this that I’m glad that I still haven’t made the time to do the 10.4.11 “upgrade”! I’ve seen a number of folks reporting issues like this.

    Here’s hoping a 10.4.12 comes out soon! (Or I wind up going to Leopard!)

    Thanks for the report,

  15. Justin Miller Says:

    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:


  16. Mark Says:


    Finally had to bite the bullet and upgrade from 10.39 to 10.4 and really wishing I hadn’t.

    Thanks for putting this up as I was starting wonder if my old G4 DP MDD 867 was getting too long in the tooth. Everything is crashing and safari barely runs!!!

    Feel like a PC user here…

    They’d better bloody fix it soon.


  17. Mark Says:

    actually 2 min after I hit submit the entire thing went bang yet again. this is insane and needs to be fixed.


  18. heavyboots Says:

    Just out of curiosity, do you know if the Safari 3.1 update snuck in a fix for this?

  19. Daniel Jalkut Says:

    I dunno heavyboots. We can hope! Time will definitely tell…

  20. heavyboots Says:

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


    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.

  21. Daniel Jalkut Says:

    Awesome! They had told me they were looking into a fix but I wasn’t sure when it would show up :) What great news.

  22. neuroklinik Says:

    FWIW, the patch for CVE-2008-0058 did NOT resolve this issue for me.

    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.

  23. Daniel Jalkut Says:

    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.

    Suggest reporting these bugs to Apple !

  24. neuroklinik Says:


    After posting this and conducting more research, I realized that there were likely more than one issue at play.

    Thanks for the heads up. I’ll file a bug.


  25. Dave Says:

    BJ Homer has figured out a way to subclass NSInputStream. There’s more info in my (and his) blog posts: http://funwithobjc.tumblr.com/post/4626637919/subclassing-nsinputstream

Comments are Closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.