Re: bad alloc

In article <56e11c1e-de9e-4e8e-8d71-a9a501e4ce17@b20g2000vbz.googlegroups.com>,
Adam Skutt <askutt@gmail.com> wrote:


Sorry for the long discussion below but short simplified and not fully
explicit answers have been previously met with dismissal based on
generalities:

Thus far, I have never attempted to provide a mechanism to
automatically distinguish OOM errors with no other information
whatsoever. Thus far I have posted a small code sample that catch()
following a new that was known to potentially be large. You simply
questionned that you didn't know what "large" was hence the example
was invalid. My answer is that I know it is potentially large because
it was designed that way.

Someone has posted experiences of observing an application recovering
from OOM errors. I have also done the same and repetitively tested it
by purposefully triggering OOM errors (yes feeding purposefully
desgined inputs to a real application in such a way that the application
eventually uses all of the available memory on a system and making
sure it still recovers).

The key is design. Design your application so that you *know*
where are the safe points of failure. You *know* how to cancel a job
safely. You *know* where the application will attempt to allocate a
large amount of memory and design this area in such a way that
recovery is possible *if* the failure is due to the requested
allocation being too large *and* much larger than what is normal.

You are the designer. You should be able to design the code in such a
way that you can ensure that "large" *potentially* recoverable
allocation happens at a known location in the code.

You keep saying "how can you distinguish recoverable vs
non-recoverable allocation?" The answer is design. You design your
application in such a way that you *plan* where the recoverable
allocations will happen.

So here is an compilable example that recovers safely from bad_alloc

----------------------------------------------
#include <iostream>
#include <stdexcept>

size_t const multiplier = 1000000;

bool doIt(size_t size)
{
  int * p = 0;
  try
  {
    p = new int[multiplier * size];
  }
  catch(std::bad_alloc &e)
  {
     // NOTE: I purposefully use iostream here.
     // I realise that this may allocate memory underneath
     // and is not a guarantee nothrow operation but here
     // it highlights that memory is avaiable.
     // In practice, you would probably not do it and just
     // try to log in a *safe* way and
     //start unrolling the stack
     std::cout << "Error: " << e.what() << std::endl;
     // allocate a bit anyway.
     int *z = new int[10];
     std::cout << "Wow, new[] still works" << std::endl;
     delete z;
     return false;
  }
  int * q = new int[5];

  delete[] q;
  delete[] p;
  std::cout << "Did it " << size << std::endl;
  return true;
    
}
int main()
{
  size_t size;
  
  for(;;)
  {
    std::cout << "Please enter allocation size: " << std::endl;
    std::cin >> size;
      
    if(!doIt(size))
    {
      std::cout << "Error happened for " << size << std::endl;
    }
    else
    {
      std::cout << "Job done for " << size << std::endl;
    }
  }
}
-------------------------------------------

This is a simplistic example but the principles are usable in a larger
application and even in a multithreaded application and it would not
matter if the try/catch was 5 function up the stack or directly around
the new.

Note that if the std::bad_alloc happens anywhere outside the
purposefully *designed* *potentially recoverable* area (i.e. when
allocating for q, z or within iostream even including the one in the
catch), then the program will terminate. This is also as-designed.

So the result:

The program can recover from OOM errors if they occur at a
particular location in the code where the designer planned to do
large allocations.

The program behave as you argued for when the OOM error occurs
elsewhere and terminate

The program can process all inputs while only being limited by the
actual current resource limits on the host (not some artificial
limits).

The program can *potentially* recover from OOM error if they are due
to input complexity. If recovery is succesfull, it can continue
processing new, less complex inputs safely. If recovery is not
successful, it will simply terminate.

The program will terminate on OOM error that happen elsewhere are are
*really* unexpected and the designer could not know how to handle.

IMO, the value of implementing this purposefully localised and
targetted OOM error recovery exceeds its cost.


IMNSHO, this is not as difficult as you suggest if you carefully
design the system for this purpose.

Yannick