Re: Mach port leakage
Re: Mach port leakage
- Subject: Re: Mach port leakage
- From: Nathan Herring <email@hidden>
- Date: Thu, 12 Aug 2010 15:46:17 +0000
- Thread-topic: Mach port leakage
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" <email@hidden> 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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden