Silent leaks?
Silent leaks?
- Subject: Silent leaks?
- From: Jack Repenning <email@hidden>
- Date: Wed, 11 Mar 2009 13:33:57 -0700
I like the Leaks template to Instruments; it's found many errors and
helped me tighten up my code quite a lot. And I also like the console
messages about things being leaked because there's no autorelease
pool. So why are they both failing me?
I just discovered that my program (http://scplugin.tigris.org/) had a
case where it should have been creating an autorelease pool and
wasn't. Naturally, there's some memory being leaked in consequence.
But despite the fact that I've used Leaks in the past to good effect,
and despite further that I've in the past spotted those log messages
about missing pools and benefitted, it appears that the particular bug
I just fixed has been in the code for years, is exercised frequently,
yet was never reported by either tool. In this case, I didn't notice
the problem until some user discovered the magical sequence of
gestures that made my program leak around 10MB/sec (which kind of gets
your attention), but now that I see the bug, it's clear that it was
leaking little bits all along.
Why didn't the tools warn me? How can I be sure there isn't something
similar somewhere else? Is there something I can do to make Leaks or
those log messages happen more reliably?
Some details:
The code that was missing a pool is a static global function, declared
inside a category file, and used as a call-back for CFMessages. Here
it is, now that it has a pool:
@implementation SCUIDaemonController(PluginSupport)
static CFDataRef SCOverlayMessageCallback (CFMessagePortRef local,
SInt32 msgid, CFDataRef data, void *info)
{
NSAutoreleasePool *nsp = [[NSAutoreleasePool alloc] init];
SCUIDaemonController *uidaemon = (SCUIDaemonController *)info;
...
It gets registered in [self -awakeFromNib]:
gMessagePort = CFMessagePortCreateLocal (NULL,
CFSTR(kSCPlugin_OverlayMessagePort), SCOverlayMessageCallback,
&context, NULL);
From the stack traces in the ObjectAlloc view of Instruments, I saw
that this function was the lowest NS-aware function in the stack;
deeper layers down to the event loop were CF, not NS. So I guessed
that none of them was building a pool for me, and further this didn't
seem to be any of the cases listed in "Carbon-Cocoa Integration Guide"
where Carbon/Cocoa programs have a pool automatically established, and
anyway an extra pool here or there isn't going to kill anyone. So I
added the pool, and there's no more bloat.
-==-
Jack Repenning
email@hidden
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden