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:email@hidden]
> Sent: Friday, December 09, 2005 9:23 PM
> To: Philip Lukidis
> Cc: email@hidden
> 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 (email@hidden)
> > Help/Unsubscribe/Update your Subscription:
> > http://lists.apple.com/mailman/options/darwin-dev/kevin%
> > 40opendarwin.org
> >
> > This email sent to email@hidden
>
_______________________________________________
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
