[IPOL discuss] Software crashes

Miguel Colom colom at cmla.ens-cachan.fr
Fri May 31 09:48:36 CEST 2013


Dear all,
now we're receiving corrected versions of the programs that didn't  
work properly.

Some of these problems seem to be similar, so I think it's worth  
making a short comment about them.

Basically, they're related to memory management and allocation.

If you known the exact amount of memory you need, allocate it exactly.  
Do not allocate more memory than you need, because it might mask a  
buffer overrun problem.

Then, once the mount of memory is known, always use the "new" operator  
in C++ or the "malloc" function in C to allocate memory.
Declaring a long array like array[9876543] will compile but it's not  
ensured that the operating system has set enough room at the stack for  
so much memory. In this case, the program will fail with a  
segmentation fault because of a (prevented) stack overflow.

If you don't know a priori the exact amount of memory, you shouldn't  
try to allocate a very long array of an arbitrary size. This is a  
waste of memory and it doesn't even ensure that the program won't fail  
because of a buffer overrun problem. Again, this only masks the problem.

The solution in this case is to allocate an initial estimation of  
memory and during the execution control if it's enough or not. If it's  
not, then
1) Create a new array whose size is double.
2) Copy the contents of the array to the new one.

You can write a function that does this and changes the pointer to the  
allocated memory, all transparently.

This strategy, called geometric expansion, gives an amortized cost  
between memory waste/cost of copying [1].

Best,
Miguel

[1]  
http://en.wikipedia.org/wiki/Dynamic_array#Geometric_expansion_and_amortized_cost

Quoting Miguel Colom <Miguel.Colom at cmla.ens-cachan.fr>:
> Dear all,
> we've observed some programs crashing at the production server.



More information about the discuss mailing list