C++ Question A Free Memory leak checker for VC++

[jedidia]

It's not caused by cbGetRadiationForce. I don't always know what the second or third lines in the stack trace want to tell me, but the cause of the leak is always called in the first line.

 

[Enjo]

In a nutshell, you need a delete statement for every new statement. Though stuff often becomes a bit more complicated than this...

Or write safe by wrapping your allocation into constructors and deallocation into destructors that are guaranteed to be executed (RAII). Memory leak check tools are great for checking but writing safe code using C++ features is the first thing to do.

 

[jedidia]

Or write safe by wrapping your allocation into constructors and deallocation into destructors that are guaranteed to be executed (RAII).

Well, that's what we all try, but pointers are like pokemons... it's tough to catch them all :lol:

 

[orb]

I never did anything with clbkGetRadiationForce ?! :blink:

    g:\orbiter 2010 p1 - main\orbitersdk\samples\atlas412_stg1\1st_main.cpp (883): Atlas412_stg1.dll!ovcInit + 0xA bytes
    0x0047B83E (File and line number not available): orbiter.exe!VESSEL3::clbkGetRadiationForce + 0x33DE bytes

I don't think clbkGetRadiationForce + 0x33DE (13278) bytes is still clbkGetRadiationForce. No single function in Orbiter should be so large. The clbkGetRadiationForce is just the last exported function in Orbiter before that code. It's some internal "unnamed" Orbiter function that got called by another function in completely different part of Orbiter.

 

[mjessick]

> Would be great to get hold of a free static analyzer too

CppCheck does good work. It doesn't catch everything. It's primary concern is low false positives. It is getting steadily better.

http://cppcheck.sourceforge.net/

Make sure you push the compiler warning level to the highest. It is intended to work along with the information provided by the compiler.

Using tools like these is one of the best ways to improve your coding skills toward the "good" level. (They basically provide you constant feedback.)

The first thing I do when reviewing code is run the compiler and CppCheck, valgrind on Linux, (and our other non-free tools) against it. I don't want to see anything reported. In an industrial setting, the next 50 people to do the same will have to spend time to evaluate each report as well. Don't waste our time by using constructs that "but it does the same thing as the non-warning version".

I just went through and removed hundreds of lines of errors put into our code at work by an inexperienced C++ programmer. All of these produced warnings either in the compiler or CppCheck.

- Matt

 

[Face]

Fellow coding-noob here, is this a problem that doesn't happen in "garbage collection" languages? Or is that something else?

Memory leaks can happen in GC languages. They are just not common, because the explicit memory house-holding is not necessary.

If you have a complex class architecture and - especially - use event handlers, you can run into logical memory leak problems very fast with GC languages. Of course it depends on the GC algorithm itself. There are memory profiler utilities to deal with this things.

Because those problems do not manifest themselves as a typical CTD like with native code, but instead simply increase the memory usage of the process, people have the false notion about GC languages creating memory hogs. More often than not, a short profiler session can cut your usage down 90%, just by getting rid of those thousands of temporarily instanced result objects that registered a model event, but forgot to unregister it again. But then again, if you make it easy to "new" without "delete", be not surprised to see it over-used.

Here and there, it is always a good thing to keep your system's memory in mind while laying out a program's structure. No language or framework will save you from being stupid.

regards,
Face

 

[agentgonzo]

It's one of the common (and very dangerous) misconceptions that GC'd languages aren't susceptible to memory leaks.

GC works by finding out what dynamically allocated memory objects aren't referenced anymore and releasing them. A common memory leak situation in GC'd languages that comes from the misconception that "you don't get leaks in GC'd languages" is where you dynamically allocate memory and keep references to it but no longer use the references (logically) in your program. The GC can't delete them because they are still referenced even though you never have the intention of ever using them again.