Re: Leaks not showing my leak
Re: Leaks not showing my leak
- Subject: Re: Leaks not showing my leak
- From: Tom Bernard <email@hidden>
- Date: Thu, 14 Jul 2005 21:14:55 -0600
First, Thanks again to those who responded. Dave, your comments confirm what
I am seeing; leaks of small allocations (16 bytes - 1024K bytes) are
reported with 50 - 100% accuracy. As I increase leakSize (2K - 10K)
reporting accuracy drops from 50% down to 10%. Leaks of 100K and larger are
not reported.
I see myself as closer to "newbie" than "expert" so please salt the
following to taste: Why are you interested in byte patterns that point to
the middle of an allocation? Consider the following:
const size_t leakSize = 31415927+1; // 31,415,927+1
- (void)awakeFromNib;
{
myPointer = malloc(leakSize);
if (!myPointer)
{
printf("allocation failed\n");
[NSApp terminate:nil];
}
long *tempPointer = myPointer;
long i, loops = leakSize/4;
for (i = 0; i < loops; i++)
{
*tempPointer = '5555';
tempPointer++;
}
free(myPointer+1024);
printf("placeholder for debugging\n");
}
The free() call results in a scolding:
Leak Study(298) malloc: *** Deallocation of a pointer not malloced:
0x139e8000; This could be a double free(), or free() called with the middle
of an allocated block; Try setting environment variable MallocHelp to see
tools to help debug
And the memory in question is not freed. So if I receive a pointer from
malloc, save it in myPointer, and then destroy myPointer, say by
incrementing myPointer to iterate through the allocation, then I have leaked
the block that was referred to by myPointer since I no longer have a valid
pointer back to the block with which I can free the block. Leaks should
report this leak. Would you save a lot of work by only seeking references to
the start of the block?
Also, doesn't malloc return long-aligned blocks? Can malloc ever return
byte-aligned blocks? If malloc always returns long-aligned blocks, then can
leaks safely ignore byte patterns that point to an odd address? I chose to
initialize my allocations with '5555' with this in mind.
I attempted to file a bug report against leaks, but Bug Reporter dumped my
efforts with an erroneous reference to using the "Back" button so I filed a
bug report against Bug Reporter instead. When I hear back that Bug Reporter
has been fixed, I will file a report against leaks and let you know the
tracking number.
Best regards,
Tom Bernard
email@hidden
on 7/13/05 11:13 AM, Dave Payne at email@hidden wrote:
> On Jul 11, 2005, Tom Bernard <email@hidden> wrote:
>
> I wrote a small app to see the command line tool leaks in action. The app,
> Leak Study
> <http://bersearch.com/MacOSXSoftware/TomsCocoaSoftware/Leak.Study.050709.001
> <http://bersearch.com/MacOSXSoftware/TomsCocoaSoftware/Leak.Study.050709.0013.
> zip>
> 3.zip
> <http://bersearch.com/MacOSXSoftware/TomsCocoaSoftware/Leak.Study.050709.0013.
> zip> >, waits 15 seconds, then sets up a repetitive timer to leak 1M every
> 10 seconds. When I run leaks after each allocation, leaks shows 2 leaks that
> appear to belong to Cocoa (see the stack trace), but does not show the 1M
> leak allocated by my app. Leaks does show the allocation for the app
> increased by a megabyte for each timer event.
>
> The attached sample is after several allocations and should show each of
> those allocations as a 1 megabyte leak. The sample only shows the 2 leaks
> that occurred at launch.
>
> While checking the archives, I saw a reference to a bug with dead-code
> stripping that affected the leaks tool, and another reference to zero-link.
> For what its worth, I rebuilt the app with dead-code stripping and zero-link
> disabled which gave the same results.
>
> Why is leaks not detecting my 1 megabyte allocation as a leak? What am I
> missing?
>
> Tom, thanks for your report. It appears that you've found a problem in
> 'leaks'. 'leaks' uses a conservative algorithm of looking through all the
> writable memory regions in your process, searching for 4-byte patterns that
> appear to be pointers to malloc blocks. But, it currently considers anything
> that appears to be a pointer into anywhere in the middle of a malloc'ed block
> to also be a reference to that block. With blocks of 1 MB, it's finding a
> number of 4-byte patterns that point into the middle of your malloc'ed
> blocks. This technique reduces the risk of "false positive" reports of leaks,
> but is unfortunately more likely to miss large leaks.
>
> We'll look at improving the heuristics for this for a future release.
>
> Note that the MallocDebug application uses a different algorithm for detecting
> leaks, and I do see it reporting those large leaks in your test application.
>
> - Dave
>
>
_______________________________________________
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