site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Thanks for your answer. The third party installed callback is empty for now, as I'm writing a test client. But if it did call back into the workloop somehow, wouldn't the stack eventually bust? Would the stack be automatically extended after a generated exception, or would the program crash or get corrupted? In any case, as the 3rd party callback does absolutely nothing, and returns nothing (it is void), I can't see this being the issue. However, this is something I definitely have to consider, so thanks for pointing it out. I guess I can have a worker pool to take care of this. Perhaps this is the preferred approach in any case. But say the stack was growing larger and larger, is there a diagnostic utility to verify this? Yes, you're quite right about extracting the packet, I'll put that in. Is there any tool for diagnosing CF type leaks? thanks, Philip Lukidis
-----Original Message----- From: Kevin Van Vechten [mailto:kevin@opendarwin.org] Sent: Friday, December 09, 2005 9:23 PM To: Philip Lukidis Cc: darwin-dev@lists.apple.com Subject: Re: CFMessagePort memory leak issue
Is the "3rd party" callback entering into the run loop again? If so, you're probably recursing and the stack keeps getting deeper...
Also, you should ensure that the data parameter to MessagePortNotificationCallbackFn is at least sizeof (PORT_PACKET_FORMAT) bytes long before calling CFDataGetBytes, otherwise you may encounter unexpected results.
- Kevin
On Dec 9, 2005, at 2:38 PM, Philip Lukidis wrote:
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; } }
thanks for any insights,
Philip Lukidis _______________________________________________ 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/kevin% 40opendarwin.org
This email sent to kevin@opendarwin.org
_______________________________________________ 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