Program crashing: memory leak?

I have a fairly simple program, which reads a video and saves its frames into a double array of ofTexture objects (with the eventual goal of loading many videos into a large 2-dimensional array of arrays of ofTexture objects). I got this working several times, but as I started to increase the number of videos read (to around 20), the program started crashing the moment it started to execute. Now, I can’t get the program to execute at all (though it compiles fine).

I don’t have much experiencing with identifying, diagnosing and fixing memory leaks, but I suspect this might be one. But I’m not sure how to tell, what might be causing it, or how to fix it.

You can grab the DEV C++ source here:

Does anything look suspect?

And how is one supposed to diagnose this stuff? The program just crashes (Console window opens, does some printf statements, and then closes).



The way you are allocating ofTexture using arrays of pointers is a little risky.
For info on this kind of thing have a read here:±faq-lite/f-…-#faq-16.16

That doesn’t mean this method won’t work, it’s just more error prone.

At a glance, I’m wondering why you are doing the following:

       printf("Deleting pixels array\n");  
       delete pixels;  

You haven’t allocated anything to this variable…it’s just a pointer, so you shouldn’t need to delete it.

hi - when I comment out that delete, it runs fine. Grimus is right, you don’t have to delete anything, ofVideoPlayer::getPixels() is not allocating anything – we will add this fact to the documentation.

for debugging, the best thing is:

a) printfs everywhere
b) commenting things out backwards until they work
c) identifying specific calls (in this case, delete pixels) that cause crashes

in this case, adding your own delete to OF stuff will just be guaranteed to fail - we are handling our own memory.

there are debuggers, and you can setup dev-c++ to add debugging info to the exe, but I couldn’t get meaningful data. typically, debuggers will show you exactly what is causeing the crash, or, what is just after the thing that causes the crash, because typically you will write a line like “delete pixels” and everything will continue to run, but the next time it goes to do something with the movie it wont work. debugging in IDEs, like devc++, and vidual studio, you can set breakpoints and watch memory - it’s different in different IDEs – I tend to be able to do most all of it via printfs, but some people love debuggers and stepping through code - it’s useful if you have deeply nested code that crashes.

wit dev c++ you should also be aware of “clean”, this remove object code and can be useful if you see absoute voodoo as you are coding. it’s not a commercial compiler and as such, can be buggy, especially if you start hacking h files and #defines, it doesn’t always recompile all the cpp files, so you will see sometime get int weird situations. clean and build all just to make sure it’s not devcpp voodoo.

the thing about c++ is that it can be mad fast, because there is 0 error checking happening, so you have to be way more conscious of what you do with memory. it’s not that hard once you get into, but it requires alot of attention.

then there are typical things that could go wrong:

a) access violations (writing to memory you don’t have), caused by off by one errors, deleting objects that you need to reuse, calling functions of OF in the wrong order, etc

b) memory leaks - allocating memory that you don’t need to - we really fight against this in of - and while we do wind up with small mistakes (in 0.04, ofImage setpixels is bad and needs fixing) we’ve tested most objects like ofVideoPlayer and they are not leaking - they allocate memory when you load them, they are constant when they play and they are being freed when you unload them. one thing in your own code is to be super conscious of the word “new” where it’s used and how often. (ie, news in a for loop in update would be very bad).

c) math errors - / by 0, - just be careful with the math operations

those are the basic things that can go wrong, and after that there are things which are more esoteric, and that’s what this discussion forum is about. For example, in the “H” file, there is a practial limit to ho much memory you can ask for. it has to do (I think) with the heap - there is very little documentation of this, so it’s one of those curious things where it works one way and no another, but by sharing our experience here we can see what problems folks have and how they solved them.

hope that helps !
take care,