Thread: computer crashing when running larger data, memory problem?

I am using lapack/blas implementation for my matrix operations (that operates in fortran). The rest of my code is just allocating and de-allocating memory blocks for the matrices. I need to loop through my data sets many iterations to compute my final product. So far it works for 200 runs but the computer freezes for 500 runs. Would anyone know what is the problem or where I can read up about this? People I have talked to think it's a memory-type problem but I've been careful to always free up the memory I use within a function/ loop. So is it my code or because of the lapack library? Hopefully someone can point me in the right direction. Thanks

Could be that allocating and freeing blocks of data is not a symmetrical operation. Internally the memory blocks that are allocated for the user are likely increasing in their locations... until the end of the user-memory space is reached. Then some clean up is attempted so that subsequent allocation requests start at the base again. By that time additional fragmentation may have occurred.

I've run into problems when attempting to do rapid malloc / free cycles.

Can you allocate just once and reuse the block each time? Perhaps allocate enough memory to accommodate the largest anticipated matrix.

Post the problematic code snippet here.

m -= mrl? Are you sure? Why do you even think that lands in memory you own.

Well, I mean, I see what it does: if you say your array goes from 8 to 10, then you allocate three rows, and then move the pointer back so that when you say "give me the eighth row" it ends up in the right place. I just don't know that you can guarantee that it works; and if you somehow lose track of your minimums and maximums it for sure won't work.

And when you free, you should be sure to add that nrl and ncl back beforehand.

One other thing: Are your matrices the same size for each of these 500 runs? If your matrices go from 200x200 to 500x500, that six-and-a-quarter times as big....

I concur with tabstop. Freeing will need to add the offsets back in so that the correct address is referenced.

Also, any failure to allocate memory is not trapped properly. Yes you've generated an error but the code continues as if everything worked. Very dangerous.

Your ddmfree function should free the column's elements by looping ncl to <= nch. But you don't pass those arguments. Whoops.

Then m + mrl should be freed instead of plain m.

There is no need to assign NULL but you can if you want.

oooh thanks for the help
i guess when i'm running my new code it's not crashing since my ncl and nrl are always 0 anyways.

Some of the matrices do change sizes for the 500 iterations. like from 3x1 to 3x10. They're not very big. And the ones that stay constant are like 3x 3000. it's probably better declaring those ones just once huh, but i can't declare them as global variables because of other restrictions.

Well, try to make all the corrections first. See if allocating and freeing hundreds if times causes any other issues...

Whenever I think I have malloc issues I write some encapsulating functions around malloc() and free() which print out the pointers passed to them... I go through that and make sure the address match, and any nested frees are performed in the reverse order as mallocs - just in case memory fragmentation can be reduced that way.

yes it works fine now. Even when i run larger data like 2000 iterations.......it just takes a while. I was wondering if the memory assignments would take up much time? Or it's probably my other operations.