Investigate what happens if STL allocation causes OOM

[maykov]

STL relies on exceptions to handle OOM. We should check that opreator new is not overloaded to return NULL. We should also add exception handlers into all high level handler functions.

[spetrunia]

I think I have accidentally hit this on a debug build. The following happened:

2015-05-24 00:36:35 10087 [Note] RocksDB: Finished filtering dropped index 202
2015-05-24 00:36:35 10087 [Note] RocksDB: Finished filtering dropped index 197
2015-05-24 00:36:35 10087 [Note] RocksDB: Finished filtering dropped index 198
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

[mdcallag]

I got that once

…

On Sunday, May 24, 2015, Sergei Petrunia <notifications@github.com> wrote: I think I have accidentally hit this on a debug build. The following happened: 2015-05-24 00:36:35 10087 [Note] RocksDB: Finished filtering dropped index 202 2015-05-24 00:36:35 10087 [Note] RocksDB: Finished filtering dropped index 197 2015-05-24 00:36:35 10087 [Note] RocksDB: Finished filtering dropped index 198 terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted (core dumped) — Reply to this email directly or view it on GitHub <https://github.com/MySQLOnRocksDB/mysql-5.6/issues/52#issuecomment-104989113> .

-- Mark Callaghan mdcallag@gmail.com

[igorcanadi]

huh yeah. we never really looked at what happens when OOM. we should never corrupt the data, but rocksdb will likely crash hard.

[maykov]

So it is important