gamedevlists-windows

RE: [GD-Windows] memory leak?

[David N. <dno...@mi...>]

> [C] Lazy C runtime library is hanging on to
>   memory after all allocations are freed
>   just because it is likely you'll want
>   more memory again in the near future
>   -- and maybe it can avoid expensive
>   system calls.
>=20

STL hangs on to memory that it pools. It will reuse it later. And it
will be properly freed when the CRT shuts down (and it will be freed,
doesn't rely on the process cleanup). This was bothering as I couldn't
tell what were real leaks from STL 'leaks', however, there was a way of
either forcing the stl to free or making the leak detector work. I'll
dig up my home code tonight and post an answer.

David

Re: [GD-Windows] memory leak?

[Rich <leg...@xm...>]

In article <000001c2868f$f0b82340$6e01a8c0@HOOKDELL220>,
    "Brian Hook" <bri...@py...>  writes:

> > A good memory tracking subsystem is important to any decent-size 
> > project.
> 
> This can't be emphasized enough.

I've used these before, and they are handy.

I've found tools like Purify to be more thorough than anything I could
write myself, however.  These days I would just buy a copy of Purify
instead of writing my own memory allocation tool.  I think it even has
the debug breakpoint stuff you mentioned.
-- 
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    izfree: Open source tools for Windows Installer
            <http://izfree.sourceforge.net>

RE: [GD-Windows] memory leak?

[Brian H. <bri...@py...>]

> I've found tools like Purify to be more thorough than 
> anything I could write myself, however.

BoundsChecker et. al. do provide some facilities such as API
verification and stack corruption that are hard to roll on your own
transparently, but writing your own still gives you a lot more
flexibility than going off-the-shelf.  And mine just automatically works
with all my projects and doesn't incur any special startup tasks or
overhead.

More importantly, writing your own will give you a solution that's
cross-platform and works in any environment.  If you have a leak that's
manifesting on Linux but not Windows then it can be kind of frustrating
trying to find it.

Brian

Re: [GD-Windows] memory leak?

[Colin F. <cp...@ea...>]

2002 November 7th
Thursday

I wrote my own routines for allocation and free,
which essentially wrap malloc() and free(), just
to get a rough idea of total memory use -- and
detect some leaks.

Let's say I override the "new" and "delete"
operators, too.  (Something I haven't tried yet)
Can I get STL to use the overrides without 
explicitly mentioning an allocator in all of
my STL uses?

Or is it more reliable to just go though the
code and change things like vector<T> to
vector<T,MyAllocator>, and thing like
vector<string> to 
vector<string<MyAllocator>,MyAllocator>.
(NOTE: I have no idea if that's how you
change the allocator for "string"!
I remember something like "basic_string"
making life interesting for me once.)

--- Colin
cp...@ea...

RE: [GD-Windows] memory leak?

[Andrew G. <ag...@cl...>]

Yeap, the importance of having identical (modulo hideous CRT bugs) memory
allocation behaviour across platforms can't be understated. Also if you're
working on consoles then a custom memory manager is pretty much vital, even
small degrees of fragmentation can really hurt you.


Andy @ 
Climax Brighton 



> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 07 November 2002 19:15
> To: gam...@li...
> Subject: RE: [GD-Windows] memory leak? 
> 
> 
> > I've found tools like Purify to be more thorough than 
> > anything I could write myself, however.
> 
> BoundsChecker et. al. do provide some facilities such as API
> verification and stack corruption that are hard to roll on your own
> transparently, but writing your own still gives you a lot more
> flexibility than going off-the-shelf.  And mine just 
> automatically works
> with all my projects and doesn't incur any special startup tasks or
> overhead.
> 
> More importantly, writing your own will give you a solution that's
> cross-platform and works in any environment.  If you have a 
> leak that's
> manifesting on Linux but not Windows then it can be kind of 
> frustrating
> trying to find it.
> 
> Brian
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>