site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Le 12 août 2010 à 17:22, Nathan Herring a écrit :
I'm trying to track down a case where we appear to be leaking Mach ports, and have a repro case where if our code is called via [self performSelectorInBackground:@selector(myCode) withObject:nil], we appear (via the Activity Monitor) to leak exactly one port. This doesn't occur if it happens on the main thread, and it doesn't occur with other calls. :/
I've tried using Instruments and a custom DTrace command to log calls to mach_port_allocate(_qos|_full)?, mach_port_destroy, and mach_port_deallocate to see if I can figure out the culprit, but it doesn't appear to show up. Plus there're a bunch of calls to mach_port_deallocate that don't seem to have a matching allocate (which is a different problem). Am I missing some major mechanisms for ports to be called into existence or destroyed?
deallocate release a reference on a send port. There is many way to get this kind of port. You can receive it from an IPC call, create it from a receive port or from an other send port, etc… There is also a call equivalent to "retain" that increase the reference of the port and should be balance by deallocate call. What do you mean by "leak" ? It creates one port each time you call the method, or it create it once, and keep it alive for the process lifetime ? -- Jean-Daniel _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... This email sent to site_archiver@lists.apple.com