[SOLVED] Some questions about memory leaks
-
Hello,
I have several questions concerning memory leaks.
I am under the impression that a memory leak is when the computer's memory becomes full of random data from a program. Because there is a bunch of unused data sitting in various addresses it can cause a SEGFAULT when another program tries to access that address. Is this an accurate overview of a memory leak?
I am assuming that a memory leak can be created by my program when I create a variable or object and never use it. Do I need to 'destroy' the variable or object when I'm done using it? If so how do I do this?
I have a program of over 2000 lines of code. Relatively recently I made a section of the program that created and manipulates a QList (there have been a few threads about this floating around the forum). Whenever I try to manipulate the QList (i.e. prepend(), size(), etc.), it causes my application to crash. The crash report would indicate a segmentation fault, but various people have told me that my usage of the QList is perfectly valid. I have also heard that the problem may lie in an arbitrary section of my program writing data to an address that the QList is trying to access. I believe this would be an example of a memory leak leading to a segmentation fault. Is this true? This is easily the biggest obstruction I've come to in my programming career so far (which is admittedly short and just starting :) ).
How can I find the source of the memory leak? Do tools exist to help me do this? If/once identified, how would I stop the memory leak?
Thanks for your help! I know this is probably an amateur question, but I really need help :(
-
Hi,
No it's not that, a memory leak is simply a object that you are creating on the heap and that you never destroy, hence memory consumption rises and in the end your application might crash if e.g. you allocate that object many times.
What you could be doing however is e.g. allocate something on the heap, give the pointer to that thing somewhere else, delete the object pointed to it in yet another place which will leave you with dangling pointers. The next time you use that point you'll be trying to reach a memory region that is already freed hence a segmentation fault.
Hope it helps
-
bq. What you could be doing however is e.g. allocate something on the heap, give the pointer to that thing somewhere else, delete the object pointed to it in yet another place which will leave you with dangling pointers. The next time you use that point you’ll be trying to reach a memory region that is already freed hence a segmentation fault.
What is this called? Sifting through thousands of lines of code to find dangling pointers seems nigh impossible, is there a quicker way to find them? Once I find them how can I fix them? What else could be an explanation for the QList causing the program to crash?
Thanks!
-
Bad memory management ;)
One thing you can use on your code is a static analysis tool like cppcheck. It should point you to some errors on your code. IIRC it will also warn you if you are allocating things and not deleting them. BUT, it cannot guess that some memory you are allocating in one class can be release in another one. However it should help you improve things.
-
Like SGaist said what you describe is memory corruption, not a memory leak.
Memory leak occurs when any part of memory you allocated becomes inaccessible (nothing pointing to it anymore). Most of the cases is caused by forgotten delete.
Memory corruption occurs when you overwrite by mistake something you're not suppose to and this makes app behavior unpredictable. These are the hardest to find, because their symptoms usually are random or occur in totally unrelated (seemingly) parts of the program.There are many types of memory corruption. Some examples:
@
int a[3];
a[3] = 42; //buffer overrun
int* b;
b = 42; //use of uninitialized pointer
int c;
int d = 2c; //use of uninitialized variable
int* e = sumeFunc();
e = 42; //use of potentially null pointer
intf = new int();
delete f;
*f = 42; //accessing destroyed variable//and many more
@My usual method to hunt these is to first fish for any bugs. Often by fixing one bug you fix 3 more you didn't know about and spot one or two other/related.
There are tools that can help to some extent. For example "VLD":https://vld.codeplex.com/ has been invaluable to me for detecting memory leaks. While not directly causing segfaults, fixing these often lead you to spotting a potential memory corruption. Another useful tool I use is "cppcheck":http://cppcheck.sourceforge.net/ - a tool for static analysis of the code. It can spot many logical, structural and syntactical problems in your code before you even compile it. Depending on the tools you use, your compiler or IDE might offer some help too. For example MSVC offers "SDL":http://msdn.microsoft.com/en-us/library/jj161081.aspx switch to the compiler which helps detect things like use of uninitialized variables and pointers and buffer overrun errors. -
vld is a library, so it's pretty much as any other library.
cppcheck is an external program. It doesn't know about your IDE (creator). You just point it to where you keep your project.
sdl is a compiler switch so you just pass it to the compiler in your .pro file -
Yeah, the tools I listed are all for windows (that's what I'm on mostly).
Clang has some nice tools I heard. Maybe this one: "clang static analyzer":http://clang-analyzer.llvm.org/
-
Ok I'll look at it.
While messing about in my program I noticed something odd and possibly important. When I try to manipulate the Qlist in my nbhistory.h/cpp file, I get a crash. However if I do the EXACT SAME operations to a QList in my mainview.h/cpp file, it works and I don't get a crash. The biggest difference between these two files is that nbhistory.h/cpp contains multiple classes, while mainview.h/cpp contains only one. Could this have something to do with it? Why would a QList work in one file but not another?
-
cppcheck is available on OS X using e.g. macports
-
Well again - it might, it might not have something to do with the bug. It might be a coincidence if one of those "multiple" classes happens to overwrite something somewhere.
No point in asking us that sort of questions I think. Without looking at the actual code we're as good as guessing.
-
Sounds weird that it would help. Maybe you just covered it up, but ok, great.
