Easily avoid memory leaks

[Bibi Uncle]

Hi!

If you are like me and love pointers, you probably found yourself in deep trouble when you have...

MEMORY LEAKS!!!​

What are memory leaks​

A lot of you have heard this word, but what is it actually?

Mermory leaks are memory used by a program, but that is not released to the operating system once finished. In C++, we are talking about when you use the operator new and that you don't delete it afterwards.​

When you create datas on the heap, or the dynamic memory using new, the operating system offers you the possibility to write to it. A memory space as big as you asked it is created and is reserved for your program. However, if you do not release it, the operating system will keep this memory reserved for you, even if your program is not running (it is not really the case on today's OS, but I'll keep it simple).​

An easy solution
​

There are many solutions, including the use of smart pointers. These can be difficult to implement, but they are usually very easy to use. I do not use smart pointers probably by pure lazyness because a lot of people have great experiences with them. Instead, I use a Visual C++ "trick".

Microsoft CRT (C Run-Time Libraries) is very useful if you know how to use it (however, when you'll come to platform independant programming, you'll be sad to leave it...). It has some special features that are not present in other libraries and it supports much better Windows programming than others, like GCC which is pretty crappy on a Windows system, but cross-platform. But that's completly another subject.

The tool I use is a function called _CrtSetDbgFlag. There are multiple ways to use the memory leaks checker, but I found that this was the easiest one. To implement it, I wrote this in the DLLCLBK InitModule function, which is called every time the DLL is loaded:

[SIZE=3]#ifdef _DEBUG[/SIZE]
[SIZE=3]_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF |[/SIZE]
[SIZE=3]_CRTDBG_LEAK_CHECK_DF); [/SIZE]
[SIZE=3]#endif[/SIZE]

The first line is a preprocessor used to only check memory leaks when I compile in debug. Why is it important to remove this when we release the software? Simply because it slows down the program.

Then, I call this useful function and I specify in the flags that I want the debugger to save the allocations and perform an automatic "dump" of the results when the DLL is unloaded. The dump can be read in the output window, where memory leaks are listed as blocks.

Orbiter's shutdown options
​

I worked with this technique since I found my first important memory leaks and it always worked like a charm. However, Orbiter is a bit special. I used to specify in Orbiter's shutdown options to terminate the process so the debugging was faster to end. I found out that Orbiter is cheating when you specify this. Actually, it does not call the destructor of the vessel when you quit Orbiter in order to save time. So, I found myself with lots of memory leaks I could not explain. Then, I found this little text in Orbiter's documentation:

Use of the "standard" method of deallocating memory is encouraged, because the other options may prevent addon modules from terminating cleanly.
The "respawn" and "terminate" options may sometimes bypass bugs in the cleanup or initialisation code of badly written addons that cause errors in the standard method.
For this reason, using the "respawn" and "terminate" options is strongly discouraged for addon developers during testing and debugging of their code, since it may mask existing problems with the code.
Addon developers should choose the standard option and make sure that their modules behave correctly in multiple simulation sessions without quitting Orbiter.

So, always use the normal shutdown options when you debug your addons!

That's it for those freaky memory leaks!

Bibi Uncle

 

[jedidia]

However, if you do not release it, the operating system will keep this memory reserved for you, even if your program is not running (it is not really the case on today's OS, but I'll keep it simple).

I just wanted to protest and then saw the text in the brackets.

I'd say the only trouble with memory leaks we have today is that they make our apps unstable...

So, always use the normal shutdown options when you debug your addons!

This, however, is something I really should do... :shifty:

 

[RisingFury]

The same problem you describe in the "Orbiter's shutdown options" can also lead to crash on exit, because of faulty pointers.

 

[Bibi Uncle]

I'd say the only trouble with memory leaks we have today is that they make our apps unstable...

That's pretty much it. However, their are some cases where memory leaks can create important injuries. For example, if your memory leak is located in a main loop (such as a game loop), running the program during a certain amount of time can cause trouble.

There are other cases where memory leaks are important, but I don't think we use it with Orbiter (cases like shared memory).

The same problem you describe in the "Orbiter's shutdown options" can also lead to crash on exit, because of faulty pointers.

That's why we must be careful with pointers. If we take care of them, we can create very effective code in terms of memory usage.