site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thread-index: Acs6MijzWRUqCtEqmU2WgiuZQmpe0QAO8DsA//+PLIA= Thread-topic: Mach port leakage User-agent: Microsoft-Entourage/13.6.0.100712 The # of ports as reported by Activity Monitory increases one per call, and remains with the life of the application instance. On 8/12/10 8:30 AM, "Jean-Daniel Dupas" <devlists@shadowlab.org> wrote:
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
-- Nathan Herring com.microsoft.devdiv.clr.os/development _______________________________________________ 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
participants (1)
-
Nathan Herring