[IPOL discuss] Software crashes

[Pierre Moulon]

Dear Miguel,

Another rigorous solution could be to use standard C++ exception checking:

try
  {
    int* myarray= new int[10000];
  }
  catch (std::bad_alloc& ba)
  {
    std::cerr << "bad_alloc caught: " << ba.what() << '\n';
  }

The [1] reference you give us, is the standard procedure that arise by
using .push_back(...) on a std::vector<X> array.




2013/5/31 Miguel Colom <colom at cmla.ens-cachan.fr>

> 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<http://en.wikipedia.org/wiki/Dynamic_array#Geometric_expansion_and_amortized_cost>
>
>
> Quoting Miguel Colom <Miguel.Colom at cmla.ens-cachan.**fr<Miguel.Colom at cmla.ens-cachan.fr>
> >:
>
>> Dear all,
>> we've observed some programs crashing at the production server.
>>
>
> --
> IPOL - Image Processing On Line   - http://ipol.im/
>
> contact     edit at ipol.im          - http://www.ipol.im/meta/**contact/<http://www.ipol.im/meta/contact/>
> news+feeds  twitter @IPOL_journal - http://www.ipol.im/meta/feeds/
> announces   announce at list.ipol.im - http://tools.ipol.im/mm/**announce/<http://tools.ipol.im/mm/announce/>
> discussions discuss at list.ipol.im  - http://tools.ipol.im/mm/**discuss/<http://tools.ipol.im/mm/discuss/>
>



-- 
Regards/Cordialement,
Pierre M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tools.ipol.im/mailman/archive/discuss/attachments/20130531/8154f176/attachment.html>