> > abort can create core dumps or start a debugger which is > > useful for me and maybe other developers, too. > > I consider abort() on OOM somewhat eccentric. abort() is for > programming errors. Resource shortage is an environmental error that is > sometimes (but not always) caused by a programming error. > > I'd rather inconvenience programmers (by making it a little bit harder > to debug programming errors that cause OOM) than confuse users with > inappropriate scary "crashes".
While I agree that abort() is not the most friendly failure method, I don't tthink it's worth trying to handle OOM gracefully. Once we hit OOM I'd say we're pretty much beyond hope. The best thing we can do is exist as quickly as possible. For the vast majority of systems there isn't any reason to believe things will somehow get better if we try again later. Initial guest RAM allocation is maybe a special case worth a polite error. OTOH if you're near the limit then there's a fair chance the -m allocation will succeed, but some later allocation will not. The only way to handle this rebustly is to pre-allocate all the memory we're ever going to need[1]. I don't see that happening. Paul [1] And make sure the kernel isn't lying about how much ram we can have.
