On Apr 30, 2009, at 8:29 AM, mac adobe wrote: I am on lepord 10.5.7 . The following issue was also seen in 10.5.5 . I am facing an issue with leaks utility in mac and would like your comments on the same . I have introduced leaks explicitly in my xcode test case program through char *p=(char*) malloc(1000*sizeof(char)); p=NULL; As per the man pages of the leaks utility , it catches all leaked memory – memory that has been allocated but has been lost and cannot be freed . As in the above said case 1000 characters have been allocated and the only pointer to the said 1000 characters has been lost by p=NULL , I expected leaks to tell me this as a leak . However it did not .
Leaks does not catch all leaked memory. It only catches leaked memory for which it cannot find a path from a global variable or stack reference to that chunk of memory. Since leaks doesn't know about the layout of items within structures and the like, it has to do a conservative scan of memory.
Thus, any stray remaining references to the memory block in question will cause leaks to not report it. This is a bummer, but is actually considerably better than the alternative of leaks spewing a bunch of false positives.
Generally, any given leak in a program happens more than once. Thus, leaks only really needs to find one instance of the leak for it to be useful -- you fix it, all of 'em are gone. Do we need to set any variable (environment ) etc to make leaks catch this error ?
The malloc subsystem provides some environment variables that can help reduce the misses on the part of leaks. MallocScribble and MallocPreScribble will cause malloc() and free() to blast known, non-pointer, byte patterns into any chunk of memory freed or allocated.
Similarly, you can clear the stack every now and then to prevent false references from stack frames that are no longer active. Something like:
char foo[16384]; bzero(foo, 16384); I had set the environment variable by export MallocStackLogging=1 which is used for displaying stack trace AFTER it identifies a leak .
MallocStackLoggingNoCompact is what you want. Has anyone else faced similar issues in the past or am I doing it the wrong way . Kindly comment .
All the time, actually. Irritates me, too. But you'll be happy to hear that the situation improves with ever release.
The underlying issue is that leaks analysis is a relatively high level bit of memory analysis that is well beyond the runtime metadata provided by a C based environment.
Also I see that 1) Many a times leaks utility gives strange behavior , identifying leaks during a run and in subsequent runs of the same test program , not identifying leaks at all .
The layout of gunk in memory is going to be different on every run. Every time a pointer is freed, some later malloc is going to return that pointer and whatever was left behind in that memory will still be there.
MallocScribble and MallocPreScribble will help quite a bit. 2) Identifying leaks only in function calls and not in main program .
Likely because of the stack; the top level frame -- the main() -- in a program isn't destroyed until program end. Thus, anything that is referred to by main(), is going to continue to look like its live. A function call generally represents a new frame hanging below the current. The next function call is gonna create a frame in the same spot and blast anything that was living their in the first function call.
Clear the stack and these are reduced. 3) Not identifying leaks at all in those cases where an external dll have been used .
Just a red herring; could be that the functions in the dll cause stack clutter or memory clutter that are pathologically undetectable. |