[SDL] ot - memory leaks

[David Olsen]

I'm not sure if I said it, but I am talking specifically about the "Fortify" 
memory manager/tracker linked to earlier in this discussion.

Okay, after perusing the internet a bit more(I had done some previously, 
promise!), I actually got it working great with the test files that come 
with it. I'll post any problems I have working it into my already 
established project (If such problems arise!)

For anyone interested in how I got it working, I'll document the steps I 
took here:
#1) Create a new empty Win32 Console Project in MSVC++2005 Express Edition 
(empty project! I always start with those...)
#2) import the two header files, and the fortify.cxx and test2.cxx (or 
test.c)
#3) Go into the Project Properties->Configuration 
Properties->c/c++->Preprocessor Options, and add "FORTIFY" to the list of 
preprocessor definitions
#4) Go into the Project Properties->Configuration Properties->Linker->Input 
options, and under additional dependencies add "msvcprtd.lib" (leave off 
the -d for release version). Then add in the Ignore Specific Library field 
"msvcirtd.lib" (again, no final -d for the release version.) Of course, not 
the quotes, just what's inside them...
#5) Compile/Build Solution! Voila!

I tested it with both Debug and release versions, as well as both included 
test programs, and they compiled without a hitch... (Well, a few warnings on 
converting an signed int to unsigned... but I just went in and explicitly 
cast them to unsigned, so the compiler would be quiet!)
Now, we'll see what happens when I try to intergrate it into an existing 
project... Wish me luck! This thing could really help me clean up my code...
-Dave

----- Original Message ----- 
From: "Christer Sandberg" <christer.sandberg at mdh.se>
To: "A list for developers using the SDL library. (includes SDL-announce)" 
<sdl at lists.libsdl.org>
Sent: Friday, August 03, 2007 5:15 AM
Subject: Re: [SDL] ot - memory leaks


> On Thursdayen den 2 August 2007, neil at cloudsprinter.com wrote:
>>would there be some kinda valgrind windows cygwin combination or is that
>> just too wierd and crazy?
> There is a memory debugger named Fortify
> http://www.geocities.com/SiliconValley/Horizon/8596/fortify.html
> Beside it can tell you memory leaks it's also capable to trap many memory
> violations. It's source based so you can use it on either system. Back in 
> bad
> old days when I was on DOS I used it a lot and was satisfied with it.
>
> To avoid memory leaks and memory violations you should focus on 
> documenting
> and a clean program structure. If a function returns a pointer to memory 
> that
> it has allocated, then always mention that in a comment:
> /* ... returns a pointer to a blah that the caller is responsible for... 
> */
> And similarly for members in structs:
> struct BAR {
>  /* Points to a FOO. The memory is owned by this BAR. */
>  FOO *foo;
>  /* Points to another FOO. The memory is NOT owned by this BAR. */
>  FOO *foo2;
> ...
> Also make separate functions to destroy your objects (and here you can 
> make
> use of you carefully typed comments):
> destroy_bar(BAR *bar)
> {
>  ...
>  destroy_foo(foo);
>  free(bar);
> }
>
> This way you can track where things come from and who owns them when the
> memory debugger tells you that you have a leak.
>
> Moving to C++ you basically have to do the same. Using STL may sometimes 
> help
> you, but if you put pointers into the containers you must be aware of the
> leak problem anyway. Using references instead of pointers in C++ may also
> help you, but it's not likely that you can live entirely without pointers 
> in
> C++.
> -- 
> Christer
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org