Server Help

[Solo Ace]

Yesterday I was looking for a program that'd help me finding memory leaks in my own programs.
I didn't find anything good, only some libraries.

How do you people look for memory leaks in your programs?
Dustpuppy was talking about calling a function at the beginning and the end of the program, which returns the used memory.
Too bad he didn't remember the function name.

I haven't really used dynamic memory allocation yet, and I only know some things that should be free()'d or delete[]'d so I doubt I did it right the last time.

Any suggestions/strategy tips for eliminating memory leaks in your code?
Please tell me.

[Dr Brain]

Valgrind.

Anything that gets created with a new must be deleteded. Arrays created with new must be delete[]ed.

If you haven't used dynamic memory allocation, you don't have memory leaks yet.
_________________
Hyperspace Owner

Smong> so long as 99% deaths feel lame it will always be hyperspace to me

[Solo Ace]

Valgrind? What's that?

I knew it worked like that heh, although VC++ wanted me to use a delete[] on a new'd non-array char * (guess that still counts as an array).

Anyway, new's aren't the problem, some of my objects weren't created with a function or something like new.
MSDN tells me to get rid of some objects by using LocalFree, I want to know what other objects should be gotten rid of in some way too.

I have used dynamic memory allocation in this program, I think I should've said I didn't really use it before.
This time I did use dynamic memory allocation, and I think I have some memory leaks at some places (and that's why I'm asking about it, eh).

Oh yeah I should've said which language I was talking about right? Well, yeah C++ obviously.

[Mr Ekted]

Well without getting fancy, every time you call new/delete, malloc/free, calloc/free, strdup/free, LocalAlloc/LocalFree, VirtualAlloc/VirtualFree, HeapAlloc/HeapFree, etc. log it to a file. Then you can look at the log later so see if all allocation calls have corresponding free calls.

If you are using MSVC and want go play around with automated stuff, look into _CrtDumpMemoryLeaks in MSDN.
_________________
4,691 irradiated haggis!

[Dr Brain]

When using C++, you should really only be using new to dynamicly allocate.

Things that aren't dynamicly allocated (local variables, global variables, etc) are created on the stack and are taken care of internally. If you are getting an object by means other than new, then it's not dynamicly allocated and MUST NOT BE deleted.

[Mr Ekted]

[Dr Brain]

In C++, you shouldn't be using raw data

Unless of course, you know what you're doing. At which point you are no longer asking questions on a forum.

[50% Packetloss]

http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.2

Actually that entire website might be of some help.

In theory, Windows should be keeping track of the memory that a program allocates so that when the program closes, all this memory can be deallocated. But in practice, windows is crap and from what Ive been told it fucks this up all the time. So while the program is running, keeping a log of your allocations and deallocations is a good idea. But after your program closes, windows has the job of deallocating the memory in which your program was running in and im sure that it will fail in deallocating all of it in some cases.

[Smong]

I would imagine the OS prepares some space in memory for the code, stack and heap. The malloc'd stuff would go in the heap and when the program is done the whole piece of memory that the program was assigned is just marked as available again.
That way it isn't necessary to for the OS to keep track of every single malloc, just the size of the heap and possibly the size of 'more' heaps if that space runs out.

[Mr Ekted]

[Cyan~Fire]

[Mr Ekted]

Raw zlib is quite fast, but I only ever use the buffer compress/decompress functions. I do any required I/O myself.

[lp_street_soldier]

[Dr Brain]

[Solo Ace]

What a bunch of discussions got started here!
Won't try to join, my English and knowledge suck too bad for making any good posts here.

At least I know what I'm trying to do, you don't see that a lot here on these forums.
I just want to know if I'm doing it right.

When I'm commenting out all the LocalFree()s _CrtDumpMemoryLeaks() doesn't output anything, although it does when I do something like

Code: Show/Hide char *p = (char *) malloc(10);

without free'ing it (just to see if I actually could make it output anything).

Anyway, since I'm not getting any output from _CrtDumpMemoryLeaks() and I followed all the instructions on MSDN's documentation so I must've done it right.

[Mr Ekted]

[Cyan~Fire]

[D1st0rt]

If done correctly, though, it can be very efficient and simple to code, since a bunch of the hard stuff was worked out in the design
_________________

[Mr Ekted]

[Dr Brain]

See, I feel it's the other way around. C++ makes it easier to write nice code, and C makes it easy to slip up and write obscure code.

Of course, I really hate the backwards compatibility of C++, as you can really do any bad stuff from C in C++.

Which is why I like Java. It enforces good OOP. Of course, it's still possible to write obscure code, but the compiler wont give up without a fight (unlike C/C++).

[Mr Ekted]

Only weak programmers need the compiler or language to enforce good design.

[Dr Brain]

Yah, and guess who's code I have to always debug? Yep, weak programmer's.

You're right, I don't need it. I can design OO in C as well as I can in C++. But not everyone can.

[Mr Ekted]

I feel your pain.

[Cyan~Fire]

Javac didn't complain one bit about this code. (I was "forced" to debug this, too. I ended up rewriting it.)

[Dr Brain]

I've seen worse. Much worse.