A CFFileDescriptorEnableCallBacks() crash

Running on OS X 10.8 Mountain Lion, we started receiving a few crash reports from Sandvox during publishing. They all had this in common:

Thread 2 Crashed:: com.apple.NSURLConnectionLoader  Dispatch queue: CFFileDescriptor
0  com.apple.CoreFoundation          0x94524c6d __CFFileDescriptorEnableCallBacks_block_invoke_0 + 13
1  libdispatch.dylib                0x900b5d0a _dispatch_client_callout + 46
2  libdispatch.dylib                0x900b74be _dispatch_barrier_sync_f_invoke + 39
3  libdispatch.dylib                0x900b7495 dispatch_barrier_sync_f + 87
4  libdispatch.dylib                0x900b9c92 dispatch_sync + 45
5  com.apple.CoreFoundation          0x9447ca1a CFFileDescriptorEnableCallBacks + 202
6  com.apple.CoreFoundation          0x94483b36 constructCFFD + 134
7  com.apple.CoreFoundation          0x94483a80 fileOpen + 320
8  com.apple.CoreFoundation          0x94460d7d _CFStreamOpen + 125
9  com.apple.CoreFoundation          0x9448392c CFReadStreamOpen + 92

Google's search results for "CFFileDescriptorEnableCallBacks crash" show nothing helpful (hence this post — hopefully it shows up as a result now!).

Some poking around with Instruments revealed that we had a ton of file descriptors opened by the URL-loading system, but not yet closed. Must be a bug of Apple's in 10.8, right? Nope! More testing revealed our KSCrypto code was  actually the culprit (fixed now of course), accidentally firing up wasted URL connections. The way that was happening in Sandvox meant they could take a very long time to run, and potentially exhaust the number of file descriptors available.

If you run into similar behaviour, I'm sure it'll be quite a different bug. But I think the moral of the story is that if CFFileDescriptor code is crashing, there's a good chance you've exhausted the supply of file descriptors; use Instruments to search for such leaks.

© Mike Abdullah 2007-2015