Thanks for your reply, I'll see what leaks thinks about this.
Philip Lukidis
> -----Original Message-----
> From: Stéphane Sudre [mailto:email@hidden]
> Sent: Friday, December 09, 2005 6:21 PM
> To: Philip Lukidis
> Cc: email@hidden
> Subject: Re: CFMessagePort memory leak issue
>
>
>
> vendredi 9 décembre 2005, à 11:38 PM, Philip Lukidis a écrit :
>
> > Hello, I have a strange issue when sending messages on
> CFMessagePort.
> > I
> > will describe the general architecture first. I have a
> daemon, which
> > communicates with a framework (shared library) using UNIX
> sockets.
> > That
> > seems to work fine. However, I need to provide 3rd party
> applications
> > with
> > callbacks. The daemon sends a message to the shared
> library, which in
> > turn
> > must notify the 3rd party application. I've chosen to take a
> > application
> > supplied callback and callback context, and call it via a
> CFMessagePort
> > callback. Both the remote port and local port are in the *same*
> > process
> > space, which is the one who mapped the shared library.
> What I do is
> > send
> > when I receive a daemon message is call
> CFMessagePortSendRequest, which
> > invokes the remote port callback, which then directly calls
> the 3rd
> > party
> > supplied callback function (and passes its context). Thus the 3rd
> > party
> > never has to deal with CFData references, or gets its hands on the
> > ports.
> >
> > However, I'm seeing a memory leak over a long time. When I simply
> > invoke
> > the 3rd party callback without going through
> CFMessagePortSendRequest,
> > the
> > private memory of the client process stays pretty constant.
> However,
> > when I
> > use the CFMessagePortSendRequest, the private memory
> balloons in size
> > over
> > several hours. Note that my reply mode for the
> CFMessagePort is NULL,
> > and
> > my timeouts are zero (see code below). Also the remote
> port callback
> > returns NULL. I'll include the relevant code below. Note that if I
> > allocate/free on the CFData for the message, but simply
> invoke the 3rd
> > party
> > supplied callback without calling CFMessagePortSendRequest,
> I have NO
> > leak.
> > So my management of the input data would appear to be correct, and
> > somehow
> > my calls to CFMessagePortSendRequest precipitate the leak.
> Can anyone
> > see a
> > memory leak here?
> >
> > // REMOTE PORT CALLBACK- note that it returns NULL
> > CFDataRef MessagePortNotificationCallbackFn(
> > CFMessagePortRef local,
> > SInt32 msgid,
> > CFDataRef data,
> > void *info
> > )
> > {
> > PORT_PACKET_FORMAT packet;
> > CommonContext* pContext = (CommonContext*)info;
> >
> > memset(&packet,0,sizeof(PORT_PACKET_FORMAT));
> > CFDataGetBytes(data, CFRangeMake(0,
> sizeof(PORT_PACKET_FORMAT)),
> > (UInt8*)&packet);
> >
> > // call user registered callback
> > if(pContext->NotificationCallback)
> > {
> >
> > pContext->NotificationCallback(&packet,pContext-
> > >NotificationCallbackContext
> > );
> > }
> >
> > // don't return anything, we are in NULL reply mode
> > return NULL;
> > }
> >
> > // CODE WHICH CALLS THE REMOTE PORT:
> > if(packetToSend)
> > {
> > memcpy(&localData,packetToSend,sizeof(PORT_PACKET_FORMAT));
> > sendData = CFDataCreate(kCFAllocatorDefault,
> > (UInt8*)&localData,
> > sizeof(PORT_PACKET_FORMAT));
> >
> > if(!sendData)
> > {
> > break;
> > }
> >
> > rc = CFMessagePortSendRequest(RemoteTargetPort,
> > 0,
> > sendData,
> > sendTimeout,
> // ALWAYS 0
> > 0,
> > NULL, //
> reply mode NULL,
> > we don't wait for a reply..
> > NULL // we know
> the remote
> > port returns NULL, we don't care for this
> > );
> >
> > // we always release no matter what the return
> > if(sendData)
> > {
> > CFRelease(sendData);
> > sendData = NULL;
> > }
> > }
>
> What is leaks(1) saying? This may help you get an idea about
> what kind
> of object is leaked.
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/darwin-dev/email@hidden
This email sent to email@hidden
