Re: Networking framework crash
Everything is a file descriptor. Open files, sockets, loaded frameworks bundles, even STDIN/OUT/ERROR. You can check if you're hitting the limit of file descriptors by (temporarily) raising the number you can have open with setrlimit(). If you raise it and your app stops crashing, then that's likely the culprit. I would guess so - the default max number you can have open is 256, and 0xfe lines up with that... If your app runs long enough before crashing, you can also use lsof in Terminal to see what your app has open. Where do you get 256 from? I just inserted the following two lines of code into a random OSX GUI app and a command line tool I wrote, right after launch struct rlimit file_limit; getrlimit( RLIMIT_NOFILE, file_limit ); For the GUI app I get file_limit.rlim_cur = 9472 and for the command line I get file_limit.rlim_cur = 7168 when run from Xcode or 2560 in either case when run from the command line or double-clicked from the finder. all of which seems to indicate processes have plenty more than 256 file descriptors available by default. I thought 256 was left behind as a default long ago because it was way too small. If I’m in a bash shell and run ulimit -n I get 2560 launchctl limit shows maxfiles256unlimited That’s the only place I can find 256 and I don’t know when that is used. Finally sysctl kern.maxfilesperproc returns 10240 which I think is the absolute hard limit on the number of file handles any process can have available. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On Feb 4, 2015, at 9:49 PM, Graham Cox graham@bigpond.com wrote: On 5 Feb 2015, at 12:20 pm, Roland King r...@rols.org wrote: You should google EXC_GUARD, it’s interesting. 0x400200fe the 02 in the middle says the guard is in dup(), which it is. The 0xfe at the end tells you what file descriptor it’s on. (0xfe .. really, seems unusually if not impossibly large for a file descriptor, you got that many files open?). Well, at the point where this crashes, I haven't opened any files at all myself, though it partly depends what you mean by file in this context, and whether the lower level code invoked by NSURLSession opens files for its own use. As I said, I'm creating about 50 NSURLSessions as my app launches, which may be simply too many. I am googling EXC_GUARD but haven't found anything that breaks it down - just a bunch of people asking what it is. Everything is a file descriptor. Open files, sockets, loaded frameworks bundles, even STDIN/OUT/ERROR. You can check if you're hitting the limit of file descriptors by (temporarily) raising the number you can have open with setrlimit(). If you raise it and your app stops crashing, then that's likely the culprit. I would guess so - the default max number you can have open is 256, and 0xfe lines up with that... If your app runs long enough before crashing, you can also use lsof in Terminal to see what your app has open. Michael Nickerson ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On 6 Feb 2015, at 6:48 am, Greg Parker gpar...@apple.com wrote: You can use getrlimit(RLIMIT_NOFILE, …) to query the limit in your process, and setrlimit(RLIMIT_NOFILE, …) to attempt to raise it. The default limit may be as low as 256, depending on OS version and on how the process is launched. (Note that each two-way network connection uses two file descriptors.) setrlimit() should be able to raise the file descriptor limit to a few thousand unless your system administrator is mean. 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. I've redesigned part of my app so that a shared NSURLSession is used across all tasks for the first type of session, leaving the individual sessions for the second type, which are architecturally unrelated to the first kind and created by a completely different object, so that should help a lot in the first place. I will also up the filehandle limit to give it a bit more headroom - I would imagine in practice that 50 tasks is a reasonable upper limit that the user would create - I can add some constraints on that in my UI. 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. Anyway, thanks for everyone's replies - I have gained a lot of insight into things that I didn't have before - I haven't done much network stuff before. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
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. I don’t think that’s very graceful, no. Since the only ‘documentation’ on EXC_GUARD seems to be in the replies in devforums it’s hard to say exactly what the contract is. However that reply, to my reading, indicates means someone called a normal filehandle method on a guarded filehandle, ie violating the guard. The header file says this #define EXC_GUARD 12 /* Violated guarded resource protections */ Whereas what you seem to have here is ‘filesystem call to a guarded resource failed in some normal way I could have reported properly’. Yes you’re out of filehandles and so there’s a failure, would have been much more useful to have the original failure code logged [EMFILE] than EXC_GUARD which (again to my reading) means something entirely different and is misleading. So I’d file a bug against that one. By the way - where do all these disparate max numbers of filehandles come from? I see the launchd one, makes sense, stuff launched from bash inherits bash’s 2560, stuff launched from finder on my box also gets 2560 (why), Xcode has its own ideas, which I suppose makes some sense as debugged processes probably need more handles and whatever Graham did to launch his process in this case got 256, which I haven’t yet found a way to get a process on 10.10 to do by default yet barring making launchd launch it. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On 6 Feb 2015, at 11:18 am, Roland King r...@rols.org wrote: whatever Graham did to launch his process in this case got 256, which I haven’t yet found a way to get a process on 10.10 to do by default yet barring making launchd launch it. I simply double-clicked it in the Finder. This is on 10.10.2. Other than whatever Xcode does when you give it permission to allow the machine to be a development machine, I would say it's as standard as they come. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On Feb 5, 2015, at 3:54 PM, Graham Cox graham@bigpond.com 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-9` to list the file descriptors in a process. (The `-d 0-9` 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 gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On Thu, Feb 5, 2015, at 05:54 PM, Graham Cox wrote: On 6 Feb 2015, at 6:48 am, Greg Parker gpar...@apple.com wrote: You can use getrlimit(RLIMIT_NOFILE, …) to query the limit in your process, and setrlimit(RLIMIT_NOFILE, …) to attempt to raise it. The default limit may be as low as 256, depending on OS version and on how the process is launched. (Note that each two-way network connection uses two file descriptors.) setrlimit() should be able to raise the file descriptor limit to a few thousand unless your system administrator is mean. 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. I'm not a Core OS engineer, so I have no idea how practical this is, but I'd file a quick enhancement request anyway asking that Xcode spawn apps in an uncustomized environment. --Kyle ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On 6 Feb 2015, at 8:29 am, Graham Cox graham@bigpond.com wrote: On 6 Feb 2015, at 11:18 am, Roland King r...@rols.org wrote: whatever Graham did to launch his process in this case got 256, which I haven’t yet found a way to get a process on 10.10 to do by default yet barring making launchd launch it. I simply double-clicked it in the Finder. This is on 10.10.2. Other than whatever Xcode does when you give it permission to allow the machine to be a development machine, I would say it's as standard as they come. --Graham So did I, and I’m on 10.2.2 as well, and I got 2560 for both GUI and command line. Wonder what I did different .. perhaps it was a debug build, don’t remember, it was late, I shall try it again later. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On Feb 5, 2015, at 10:22 AM, Roland King r...@rols.org wrote: Everything is a file descriptor. Open files, sockets, loaded frameworks bundles, even STDIN/OUT/ERROR. You can check if you're hitting the limit of file descriptors by (temporarily) raising the number you can have open with setrlimit(). If you raise it and your app stops crashing, then that's likely the culprit. I would guess so - the default max number you can have open is 256, and 0xfe lines up with that... If your app runs long enough before crashing, you can also use lsof in Terminal to see what your app has open. Where do you get 256 from? I just inserted the following two lines of code into a random OSX GUI app and a command line tool I wrote, right after launch struct rlimit file_limit; getrlimit( RLIMIT_NOFILE, file_limit ); For the GUI app I get file_limit.rlim_cur = 9472 and for the command line I get file_limit.rlim_cur = 7168 when run from Xcode or 2560 in either case when run from the command line or double-clicked from the finder. Well, that'll teach me to double check before posting. I hadn't realized the max got upped. Seems like it's 2560 (I would guess it's higher when run in Xcode for debugging). all of which seems to indicate processes have plenty more than 256 file descriptors available by default. I thought 256 was left behind as a default long ago because it was way too small. Makes sense to me. I have run up against the max open files limit before when it was still 256. I am happy to see it was raised. launchctl limit shows maxfiles256unlimited That’s the only place I can find 256 and I don’t know when that is used. So, I take the above back - not running into the limit, unless maybe it's being run by launchd. Those limits shown by launchctl are what's used by anything launchd launches, unless the plist file overrides them. I wonder if that's on purpose or just an oversight? And yes, I tested that this time! I get: Feb 5 11:16:46.875 test[4252]: cur: 2560 Feb 5 11:18:00.078 test[4274]: cur: 256 (First is normal run, second is launched by launchd.) Michael Nickerson ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On Feb 5, 2015, at 7:22 AM, Roland King r...@rols.org wrote: all of which seems to indicate processes have plenty more than 256 file descriptors available by default. I thought 256 was left behind as a default long ago because it was way too small. It was definitely 256 as recently as OS X 10.8 — I know because in 2012 I was porting a server app that needed way more file descriptors than that, so I had to work with setrlimit to raise it. So it must have been raised in 10.9 or 10.10. Good. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On Thu, Feb 5, 2015, at 06:40 PM, Roland King wrote: On 6 Feb 2015, at 8:29 am, Graham Cox graham@bigpond.com wrote: On 6 Feb 2015, at 11:18 am, Roland King r...@rols.org wrote: whatever Graham did to launch his process in this case got 256, which I haven’t yet found a way to get a process on 10.10 to do by default yet barring making launchd launch it. Have you installed Server.app (or upgraded from OS X Server)? --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
Yep, I found that just after I sent my previous. Interesting, though a little difficult to relate exactly to my crash. I guess tcp_connection_get_socket() creates a file handle for the socket stream (?? guessing) and that's the one tripping the EXC_GUARD. Do you or anyone else know if there's some inherent limit to the number of simultaneous sockets that can be opened? I'm supposing that there's a 1:1 correspondence between a NSURLSession and a socket, because of the description against [NSURLSession resetWithCompletionHandler:] says: Yes there is an inherent limit to the number of sockets which can be opened. It's limited by the number of filehandles you can have open which you fin by running ulimit -n and on my machine that gives 2560 when run from a shell (oh how things have changed!), so you're probably not running into that. I really can't decide whether the filehandle you're getting the exception on, 254, is high or not. You have probably 50 sockets open but I have no idea how many filehandles a generic process 'just uses' in the course of being a generic process. Since OSX doesn't have a /proc filesystem, it's not that easy to tell. This method empties all cookies, caches and credential stores, removes disk files, flushes in-progress downloads to disk, and ensures that future requests occur on a new socket This implies that there's a socket associated with the session. Since I have also a 1:1 correspondence between my app's individual tasks and NSURLSession, I'm opening 1 socket per task as my app starts. So around 50 in my current test situation. if you aren’t opening your own files/creating your own filehandles I suspect you have a bugreport in your future. You might also try a post in CoreOS on devforums or on the networking apple mail list as that’s where Quinn hangs out. That sounds like a good thing to try. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On Feb 4, 2015, at 8:21 PM, Graham Cox graham@bigpond.com wrote: Do you or anyone else know if there's some inherent limit to the number of simultaneous sockets that can be opened? I'm supposing that there's a 1:1 correspondence between a NSURLSession and a socket, because of the description against [NSURLSession resetWithCompletionHandler:] says: This method empties all cookies, caches and credential stores, removes disk files, flushes in-progress downloads to disk, and ensures that future requests occur on a new socket This implies that there's a socket associated with the session. Network connections use sockets. Sockets use file descriptors. There is a per-process limit on the number of open file descriptors. You can use getrlimit(RLIMIT_NOFILE, …) to query the limit in your process, and setrlimit(RLIMIT_NOFILE, …) to attempt to raise it. The default limit may be as low as 256, depending on OS version and on how the process is launched. (Note that each two-way network connection uses two file descriptors.) setrlimit() should be able to raise the file descriptor limit to a few thousand unless your system administrator is mean. 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. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
No disrespect, but after 30+ years of developing, I am roughly conversant with debugging strategies. My apologies, I sent my spam before noting who I was sending it to. Of course I know you've been a coder, actually for quite a longer time than I have. There are some other considerations that you might not have looked into though. Does this happen on just one machine? If that's the case perhaps it could be a hardware problem. Try installing MemtestOSX, rebooting as single-user then: $ ./memtest all 1 Let the tests run to completion. Note that this will also indirectly test for problems with your CPU, memory controller and motherboard. Is your box overheating? If so the fans will make a lot of noise. Perhaps you found a bug in the kernel or one of the userspace frameworks. I won't insult you by telling you how to regress that but if it is in the kernel I have some insight into kernel debugging. Cheers, Mike Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Wed, Feb 4, 2015 at 7:04 PM, Graham Cox graham@bigpond.com wrote: On 5 Feb 2015, at 1:53 pm, Michael Crawford mdcrawf...@gmail.com wrote: This Spam Has Been Brought To You By: No disrespect, but after 30+ years of developing, I am roughly conversant with debugging strategies. This is not an easy one to isolate, because there's very little information on EXC_GUARD that I can find, the code is being run on a thread I didn't create, and whose provenance (calling chain) is not directly related to my high-level code (NSURLSession/NSURLSessionDataTask). It's also only just started happening in an app that has been happily running for months without a problem (notwithstanding the memory leak I discussed a couple of weeks ago that was in the same app, and also appears not to be my bug). What is new is that I may have started to hit some sort of unexpected internal limit that I hadn't previously triggered. If that's the case it may have profound implications for my app's architecture, which does create one session per task, rather than one session per app. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On 5 Feb 2015, at 2:14 pm, Roland King r...@rols.org wrote: I am googling EXC_GUARD but haven't found anything that breaks it down - just a bunch of people asking what it is. Really? Google sent me to twitter sent me to devforums sent me to eskimo1. eg https://devforums.apple.com/message/914791#914791 Yep, I found that just after I sent my previous. Interesting, though a little difficult to relate exactly to my crash. I guess tcp_connection_get_socket() creates a file handle for the socket stream (?? guessing) and that's the one tripping the EXC_GUARD. Do you or anyone else know if there's some inherent limit to the number of simultaneous sockets that can be opened? I'm supposing that there's a 1:1 correspondence between a NSURLSession and a socket, because of the description against [NSURLSession resetWithCompletionHandler:] says: This method empties all cookies, caches and credential stores, removes disk files, flushes in-progress downloads to disk, and ensures that future requests occur on a new socket This implies that there's a socket associated with the session. Since I have also a 1:1 correspondence between my app's individual tasks and NSURLSession, I'm opening 1 socket per task as my app starts. So around 50 in my current test situation. if you aren’t opening your own files/creating your own filehandles I suspect you have a bugreport in your future. You might also try a post in CoreOS on devforums or on the networking apple mail list as that’s where Quinn hangs out. That sounds like a good thing to try. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
There are all kinds of ways that your bug could be somewhere else, other than where the processor finds an illegal instruction that generates an exception that yields your panic. There are a number of strategies for dealing with this that are quite a lot easier than single-stepping with a debugger or adding lots of printfs or NSLogs. Try bisecting your code's history. If you're not using revision control, then hopefully you at least keep regular backups. Try cutting down your existing codebase into a minimal test case. Perhaps the bug will go away at some point. Add back to your build the source you just removed. Does you bug reappear? If so then remove some other code until you have the very smallest amount of source that you possibly can. If the bug is not readily reproducible, find some way to stabilize it, say by feeding it input files or network data that reliably stimulates the crash. Add assertions to your source. Even after you fix the bug, keep the assertions in your source as they are likely to catch other bugs later: assert() is the Documentation that Keeps On Testing http://www.warplife.com/tips/code/quality/test/assertion/ In my personal experience, asserting the validity to subroutine parameters yields the most productive use of my time. If that doesn't find your bug, assert that the return results of subroutine are valid. If that still doesn't find your bug, assert that class invariants are valid _outside_ of the payload code of any C++ member function or Objective-C method. A class invariant is some property of a class which always holds true, with the possible exception that the invariant may be temporarily broken within the body of subroutine. Not all classes have sensible invariants. If you find that many of yours do not, perhaps it would help to refactor your classes so that they do. Enable guard malloc in Xcode's settings. Use valgrind: http://www.valgrind.org/ Have a read of the Design for Testability section of John Lakos' most-excellent Large Scale C++ Software Design - even if you don't use C++, his section on Design for Testability will still apply for your code. Refactor your sourcebase so as to enable what he denotes as Levelization, and that I denote as Lakos Levelization. Many coders practice unit testing; Lakos Levelization combines unit testing and refactoring. The source for a levelized program is quite a lot easier to understand than the source for one which is not levelized. If all else fails, mail me off-list and I'll fix it for you for a reasonable consulting fee. This Spam Has Been Brought To You By: Mike Crawford Michael David Crawford, Consulting Software Engineer mdcrawf...@gmail.com http://www.warplife.com/mdc/ Available for Software Development in the Portland, Oregon Metropolitan Area. On Wed, Feb 4, 2015 at 5:28 PM, Alex Zavatone z...@mac.com wrote: Hard to tell without the code that surrounds it. On Feb 4, 2015, at 8:00 PM, Graham Cox wrote: Anyone seen this? My fault, or...? OS Version:Mac OS X 10.10.2 (14C109) Report Version:11 Anonymous UUID:41C0442D-1002-83C7-8C29-1DCC8E683B2F Sleep/Wake UUID: 5DE82D59-D0D8-4695-A86E-23F6ABBFAEAB Time Awake Since Boot: 30 seconds Time Since Wake: 6200 seconds Crashed Thread:7 Dispatch queue: com.apple.networking.connection.0x7fa940613300 Exception Type:EXC_GUARD Exception Codes: 0x400200fe, 0x7fa94044b9e0 Thread 7 Crashed:: Dispatch queue: com.apple.networking.connection.0x7fa940613300 0 libsystem_kernel.dylib0x7fff83900c1a dup + 10 1 libsystem_network.dylib 0x7fff86cbb3d5 __tcp_connection_get_socket_block_invoke + 60 2 libdispatch.dylib 0x7fff896f1c13 _dispatch_client_callout + 8 3 libdispatch.dylib 0x7fff896f2e5e _dispatch_barrier_sync_f_invoke + 57 4 libsystem_network.dylib 0x7fff86cbb336 tcp_connection_get_socket + 135 5 com.apple.CFNetwork 0x7fff8658e018 SocketStream::_onqueue_completeTCPConnection0(dispatch_data_s*) + 160 6 com.apple.CFNetwork 0x7fff8658e786 ___ZN12SocketStream30_onqueue_completeTCPConnectionEv_block_invoke_2 + 129 7 libdispatch.dylib 0x7fff896f6323 _dispatch_call_block_and_release + 12 8 libdispatch.dylib 0x7fff896f1c13 _dispatch_client_callout + 8 9 libdispatch.dylib 0x7fff896f5365 _dispatch_queue_drain + 1100 10 libdispatch.dylib 0x7fff896f6ecc _dispatch_queue_invoke + 202 11 libdispatch.dylib 0x7fff896f46b7 _dispatch_root_queue_drain + 463 12 libdispatch.dylib 0x7fff89702fe4 _dispatch_worker_thread3 + 91 13 libsystem_pthread.dylib 0x7fff86028637 _pthread_wqthread + 729 14 libsystem_pthread.dylib 0x7fff8602640d start_wqthread + 13
Re: Networking framework crash
On 5 Feb 2015, at 12:28 pm, Alex Zavatone z...@mac.com wrote: Hard to tell without the code that surrounds it. That's the problem - there is no code that surrounds it. I'm using the NSURLSession/NSURLSessionDataTask interface. This internally calls down into operation queues, low level networking, sockets and so on. It's also not happening consistently - I had a couple of these today and then it started working fine. I haven't seen these before either. I do kick off a lot of these sessions at once - it kinda depends on how the user has configured the app, but I'm currently testing with about 50 separate tasks, each of which opens a NSURLSession. These remain in existence and valid until the app quits (or until a particular task that owns it is deleted). Maybe that's just too many? I haven't read anything that says there is a limit to these, and I'm not sure it's going to be easy to reorganise to reduce them. On 5 Feb 2015, at 12:20 pm, Roland King r...@rols.org wrote: You should google EXC_GUARD, it’s interesting. 0x400200fe the 02 in the middle says the guard is in dup(), which it is. The 0xfe at the end tells you what file descriptor it’s on. (0xfe .. really, seems unusually if not impossibly large for a file descriptor, you got that many files open?). Well, at the point where this crashes, I haven't opened any files at all myself, though it partly depends what you mean by file in this context, and whether the lower level code invoked by NSURLSession opens files for its own use. As I said, I'm creating about 50 NSURLSessions as my app launches, which may be simply too many. I am googling EXC_GUARD but haven't found anything that breaks it down - just a bunch of people asking what it is. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
Hard to tell without the code that surrounds it. On Feb 4, 2015, at 8:00 PM, Graham Cox wrote: Anyone seen this? My fault, or...? OS Version:Mac OS X 10.10.2 (14C109) Report Version:11 Anonymous UUID:41C0442D-1002-83C7-8C29-1DCC8E683B2F Sleep/Wake UUID: 5DE82D59-D0D8-4695-A86E-23F6ABBFAEAB Time Awake Since Boot: 30 seconds Time Since Wake: 6200 seconds Crashed Thread:7 Dispatch queue: com.apple.networking.connection.0x7fa940613300 Exception Type:EXC_GUARD Exception Codes: 0x400200fe, 0x7fa94044b9e0 Thread 7 Crashed:: Dispatch queue: com.apple.networking.connection.0x7fa940613300 0 libsystem_kernel.dylib0x7fff83900c1a dup + 10 1 libsystem_network.dylib 0x7fff86cbb3d5 __tcp_connection_get_socket_block_invoke + 60 2 libdispatch.dylib 0x7fff896f1c13 _dispatch_client_callout + 8 3 libdispatch.dylib 0x7fff896f2e5e _dispatch_barrier_sync_f_invoke + 57 4 libsystem_network.dylib 0x7fff86cbb336 tcp_connection_get_socket + 135 5 com.apple.CFNetwork 0x7fff8658e018 SocketStream::_onqueue_completeTCPConnection0(dispatch_data_s*) + 160 6 com.apple.CFNetwork 0x7fff8658e786 ___ZN12SocketStream30_onqueue_completeTCPConnectionEv_block_invoke_2 + 129 7 libdispatch.dylib 0x7fff896f6323 _dispatch_call_block_and_release + 12 8 libdispatch.dylib 0x7fff896f1c13 _dispatch_client_callout + 8 9 libdispatch.dylib 0x7fff896f5365 _dispatch_queue_drain + 1100 10 libdispatch.dylib 0x7fff896f6ecc _dispatch_queue_invoke + 202 11 libdispatch.dylib 0x7fff896f46b7 _dispatch_root_queue_drain + 463 12 libdispatch.dylib 0x7fff89702fe4 _dispatch_worker_thread3 + 91 13 libsystem_pthread.dylib 0x7fff86028637 _pthread_wqthread + 729 14 libsystem_pthread.dylib 0x7fff8602640d start_wqthread + 13 --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com This email sent to z...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
You should google EXC_GUARD, it’s interesting. 0x400200fe the 02 in the middle says the guard is in dup(), which it is. The 0xfe at the end tells you what file descriptor it’s on. (0xfe .. really, seems unusually if not impossibly large for a file descriptor, you got that many files open?). That next bit 0x7fa94044b9e0 is the magic number for that particular guard and how you decode that I have no idea. There’s a suggestion that may be a pointer/object reference. So things which might cause this are using a file descriptor you gave to GCD to manage outside any context GCD gives it back to you to manage yourself. Using a close()d file descriptor which has then been re-openen by something else which ‘guards’ it. I initially wondered if there was a block invoke on a block which had been released. Have you gone back to non-ARC again? Or it’s a framework bug. On 5 Feb 2015, at 9:00 am, Graham Cox graham@bigpond.com wrote: Anyone seen this? My fault, or...? OS Version:Mac OS X 10.10.2 (14C109) Report Version:11 Anonymous UUID:41C0442D-1002-83C7-8C29-1DCC8E683B2F Sleep/Wake UUID: 5DE82D59-D0D8-4695-A86E-23F6ABBFAEAB Time Awake Since Boot: 30 seconds Time Since Wake: 6200 seconds Crashed Thread:7 Dispatch queue: com.apple.networking.connection.0x7fa940613300 Exception Type:EXC_GUARD Exception Codes: 0x400200fe, 0x7fa94044b9e0 Thread 7 Crashed:: Dispatch queue: com.apple.networking.connection.0x7fa940613300 0 libsystem_kernel.dylib0x7fff83900c1a dup + 10 1 libsystem_network.dylib 0x7fff86cbb3d5 __tcp_connection_get_socket_block_invoke + 60 2 libdispatch.dylib 0x7fff896f1c13 _dispatch_client_callout + 8 3 libdispatch.dylib 0x7fff896f2e5e _dispatch_barrier_sync_f_invoke + 57 4 libsystem_network.dylib 0x7fff86cbb336 tcp_connection_get_socket + 135 5 com.apple.CFNetwork 0x7fff8658e018 SocketStream::_onqueue_completeTCPConnection0(dispatch_data_s*) + 160 6 com.apple.CFNetwork 0x7fff8658e786 ___ZN12SocketStream30_onqueue_completeTCPConnectionEv_block_invoke_2 + 129 7 libdispatch.dylib 0x7fff896f6323 _dispatch_call_block_and_release + 12 8 libdispatch.dylib 0x7fff896f1c13 _dispatch_client_callout + 8 9 libdispatch.dylib 0x7fff896f5365 _dispatch_queue_drain + 1100 10 libdispatch.dylib 0x7fff896f6ecc _dispatch_queue_invoke + 202 11 libdispatch.dylib 0x7fff896f46b7 _dispatch_root_queue_drain + 463 12 libdispatch.dylib 0x7fff89702fe4 _dispatch_worker_thread3 + 91 13 libsystem_pthread.dylib 0x7fff86028637 _pthread_wqthread + 729 14 libsystem_pthread.dylib 0x7fff8602640d start_wqthread + 13 --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
On 5 Feb 2015, at 1:53 pm, Michael Crawford mdcrawf...@gmail.com wrote: This Spam Has Been Brought To You By: No disrespect, but after 30+ years of developing, I am roughly conversant with debugging strategies. This is not an easy one to isolate, because there's very little information on EXC_GUARD that I can find, the code is being run on a thread I didn't create, and whose provenance (calling chain) is not directly related to my high-level code (NSURLSession/NSURLSessionDataTask). It's also only just started happening in an app that has been happily running for months without a problem (notwithstanding the memory leak I discussed a couple of weeks ago that was in the same app, and also appears not to be my bug). What is new is that I may have started to hit some sort of unexpected internal limit that I hadn't previously triggered. If that's the case it may have profound implications for my app's architecture, which does create one session per task, rather than one session per app. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Networking framework crash
I am googling EXC_GUARD but haven't found anything that breaks it down - just a bunch of people asking what it is. Really? Google sent me to twitter sent me to devforums sent me to eskimo1. eg https://devforums.apple.com/message/914791#914791 https://devforums.apple.com/message/914791#914791 There’s a bunch more but they all say much the same thing. if you aren’t opening your own files/creating your own filehandles I suspect you have a bugreport in your future. You might also try a post in CoreOS on devforums or on the networking apple mail list as that’s where Quinn hangs out. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
