Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate what happens if STL allocation causes OOM #34

Closed
hermanlee opened this issue Sep 28, 2015 · 5 comments
Closed

Investigate what happens if STL allocation causes OOM #34

hermanlee opened this issue Sep 28, 2015 · 5 comments
Assignees
Labels

Comments

@hermanlee
Copy link
Contributor

Issue by maykov
Tuesday Apr 14, 2015 at 22:48 GMT
Originally opened as MySQLOnRocksDB#52


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.

@hermanlee
Copy link
Contributor Author

Comment by spetrunia
Sunday May 24, 2015 at 07:54 GMT


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)

@hermanlee
Copy link
Contributor Author

Comment by mdcallag
Sunday May 24, 2015 at 22:11 GMT


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
MySQLOnRocksDB#52 (comment)
.

Mark Callaghan
mdcallag@gmail.com

@hermanlee
Copy link
Contributor Author

Comment by igorcanadi
Tuesday May 26, 2015 at 18:34 GMT


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

@hermanlee
Copy link
Contributor Author

Comment by maykov
Friday Jun 05, 2015 at 22:40 GMT


So it is important

@gunnarku gunnarku self-assigned this Feb 12, 2016
@gunnarku
Copy link

Internal investigation completed. Behavior observed, documented, and understood for various scenarios. To decide if we'll change the status quo (SIGABRT because of an unhandled exception which leads to process teardown) will require data from the field and further discussion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants