Re: CFMessagePort memory leak issue
Re: CFMessagePort memory leak issue
- Subject: Re: CFMessagePort memory leak issue
- From: Stéphane Sudre <email@hidden>
- Date: Sat, 10 Dec 2005 00:20:54 +0100
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:
This email sent to email@hidden