site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com vendredi 9 décembre 2005, à 11:38 PM, Philip Lukidis a écrit : // 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; } } _______________________________________________ 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... 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; } What is leaks(1) saying? This may help you get an idea about what kind of object is leaked. This email sent to site_archiver@lists.apple.com