Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

MongoDB's BSON library calls abort() on malloc failure because they can't be bothered to handle OOM gracefully.


Linux supports overcommitted memory and so will lie to your application about memory availability. When I tested several common open-source applications in a memory-constrained environment none of them, except for the Java VM, handled OOM conditions gracefully. I came to the conclusion it's not worth the programming effort unless your application will specifically expect this condition to occur.


I work on systems that don't run on Linux, and those systems also have reasonable business requirements for graceful failure on OOM. This is unhelpful.


That seems completely reasonable. The only interesting case is "There was far too little storage, so we gave up early" e.g. you need 14GB, there is 186MB available, give up. I probably don't want my photo viewer to crash because I tried to open a JPEG that wouldn't fit in RAM, better it just says that's too big and I can pick a different file.

Whenever people are imagining they're going to recover despite OOM in low level components they are tripping. Their recovery strategy is going to blow up too, and then they're going to be in a huge mess - just abort when this happens.


Postgres is designed to recover on OOM in most cases.


That's nice, how well does it work in practice?


It works. Bugs have been found, and some more bugs probably exist, but I think it meets a fairly high bar of quality.


Firefox and Chrome (and thus Edge, Brave, OperaGX, etc etc) do the same for many allocations - it's safer to crash than to end up in an obscure failure path that never had its error handling exercised and may accidentally be security sensitive.


What else would you expect them to do?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: