Re: Networking framework crash
Re: Networking framework crash
- Subject: Re: Networking framework crash
- From: Greg Parker <email@hidden>
- Date: Thu, 05 Feb 2015 16:17:44 -0800
> On Feb 5, 2015, at 3:54 PM, Graham Cox <email@hidden> wrote:
>
> This is great. Running from XCode I get 7168, archiving and exporting a final build of my app, I get 256... bingo! Only the built version was seeing this crash, another reason I was having a lot of trouble debugging it.
>
> With 50 tasks, creating 50 NSURLSession, that accounts for 100 file descriptors. I'm supposing the rest come from other places - in fact each of my tasks potentially creates 2 NSURLSession, though these second ones are highly conditional on what the first ones return, and usually are NOT created, so I doubt that I was immediately creating 200 file handles.
You can use `sudo lsof -p <PID> -a -d 0-99999` to list the file descriptors in a process. (The `-d 0-99999` flag hides open files that don't have file descriptors.)
>> If you hit that limit you should see errors from various network API. File a bug report if you find some API that causing weird crashes instead of failing gracefully or halting with an appropriate error message when you run out of file descriptors.
>
> Well I'm seeing EXC_GUARD. Is that considered "graceful"? From the user's perspective it isn't, because it causes summary termination of the app which is almost always reported as "it crashed, wah!, you suck!". Ultimately this should propagate up to the NSURLSession API in some way - e.g. by returning nil instead of an object if it can't create its resources. I think one problem there is that the API is asynchronous - it creates the object which then starts a thread to open the socket - that's what the stack trace implies anyway. That would make it hard to simply not return a valid object. Not sure what the right design would be there - that's one for the networking architects to ponder I guess.
EXC_GUARD is very bad, usually on the order of use-after-free bad. Acceptable results are an error or exception from the API, preferably one that says "too many open files", or a crash log that says "too many open files". Anything that doesn't say "too many open files" somewhere is hard to diagnose.
--
Greg Parker email@hidden Runtime Wrangler
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden