[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