Re: Memory Leak
Re: Memory Leak
- Subject: Re: Memory Leak
- From: "Sean McBride" <email@hidden>
- Date: Mon, 26 May 2008 10:39:02 -0400
- Organization: Rogue Research
On 5/24/08 10:42 AM, Bill Bumgarner said:
>On May 24, 2008, at 2:38 AM, Romain Marucchi wrote:
>> How can I track all the memory leak of my C/C++ application when the
>> application close. I would like to have a list of all "not
>> deallocated" memory and where I initialize them... I check with
>> Instruments (Beta 5) and MallocDebug, but both of them doesn't show
>> me any memory leak when my application close... even if I create
>> some on purpose... am I doing something wrong?
>
>Probably not. The tools aren't generally designed to capture the
>state of an application when it closes because memory leaks at that
>point in time are generally completely irrelevant; the system will
>reclaim the memory of an application when it quits in its entirety.
Romain is probably used to using using Microsoft's dev tools. I
understand they do exactly that, print leaks when the app quits.
I disagree with your assessment. I would love to see such a feature in
Xcode. Finding leaks with Instrument/MallocDebug/leaks requires
breaking one's workflow. If Xcode printed leaks after every run, it
would be easier to find leaks _right away_ instead of weeks later when
one decides to run it through a special tool. Yes, the OS will clean
everything up, but if execution reaches the end of main() and memory is
still hanging around, there is no doubt that it is a leak. That's a
great time to check for leaks.
>However, there are cases where you might need to know. For example,
>testing for memory leaks at the end of a unit test run is often a
>great way to find leaks in framework code.
A good example. IMHO, this extends to applications, not just unit
tests. A run of an app is like one big test.
>To these ends, I usually just add a sleep() to my main() function that
>can be controlled via an environment variable...
>
>int main(...) {
> ... do lots of stuff ...
>
> if (getenv("PAUSEBEFOREEXIT")) {
> // the time it takes light to travel from the sun to mars and back
> // coincidentally, more than enough time to track down memory problems
> sleep(760 * 2);
> }
> exit(n);
>}
A good workaround given the current state of the tools, but one still
needs to perform extra steps after this. Namely attaching Instrument/
MallocDebug/leaks. As for Instruments, the docs say that to find leaks
one "must launch your process from Instruments". And as for
MallocDebug, it doesn't work with GC apps (not a problem in the OP's case).
Lastly, Romain, I suggest you read the malloc man page, you will
probably find some of the environment variables very helpful in finding
and fixing memory related problems.
--
____________________________________________________________
Sean McBride, B. Eng email@hidden
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
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