CVE-2019-5736: runc container breakout

Which caller? The immediately preceding function or the caller that invoked the application? Being able to attach a debugger certainly has value, but in production environments, and particularly in cloud infrastructure environments, that's not the most important characteristic. What you want is for things to fail fast so that the system can adjust in a timely manner; and usually fail fast to the nearest caller (at least nearest by API or contract boundary) as the nearest caller will usually be in the best position to react optimally (and if not it can simply bubble up). It's *exactly* analogous to buffer bloat--by trying to be too helpful these hacks are blunting or dropping feedback pressure, with the macro result being crappy behavior that is extremely costly to remedy, if it can be remedied at all.

The distinction between being "truly" out of memory and only being out of memory because of policy seems contrived and irrelevant, particularly in the era of nested containers and VMs.

In the context of a language like Go or Perl or simple C utilities or similar languages, aborting on allocation failure (rather than trying to implement the runtime in a way that makes it recoverable) is excused as a reasonable cost-benefit tradeoff as these programs are typically executed circumscribed contexts (microservices, CGI scripts) where the possibility of meaningful recover by higher layers up the stack is retained. But locking up the application? Sure, being able to attach a debugger has some utility, just as being able to attach a debugger to a car's breaking system which decided to fail in an open state as a convenience for the engineers. But that's hardly the most reasonable or desirable behavior in the vast majority of contexts.