4 ms·

But any process can be trying to allocate at the time your system runs out of memory, and most applications are not authored to handle malloc failing. Process

by enneff 7y ago

But any process can be trying to allocate at the time your system runs out of memory, and most applications are not authored to handle malloc failing. Process failure seems easier to work around, from what I’ve seen. Would love to hear more from someone who has contrary experience.

AnIdiotOnTheNet 7y ago
At least you can then properly blame the software for doing the wrong thing and potentially patch it. The kernel should not implement global behavior that encourages improper memory allocation failure handling.
- AgentOrange1234 7y ago
  Yes so much. The overcommit approach seems to be to say, “Most people are lazy so we shouldn’t allow anyone to brush their teeth.” Handling malloc failures isn’t rocket science.
  - pcwalton 7y ago
    Incorrectly handling malloc failures has been responsible for a lot of security problems. We are all better off acknowledging that C programmers are broadly incapable of writing correct OOM handling at scale and figuring out what to do with this fact, instead of wishing that it weren't this way.
  - the_why_of_y 7y ago
    Do you have an example of a nontrivial user-space project that has malloc failure handling that actually works, with tests and all? The one I'm aware of is SQLite. Then there is DBus, whose author disagrees with your assessment. https://blog.ometer.com/2008/02/04/out-of-memory-handling-d-bus-experience/ https://blog.ometer.com/2008/02/04/out-of-memory-handling-d-...
    - wahern 7y ago
      Lua, various OS kernels Like any aspect of writing software, how you approach the problem effects the complexity of the final product. If someone doesn't make a habit of handling OOM, then of course their solutions are going to be messy and complex; they're going to "solve" the problem in the most direct and naive way, which is rarely the best way. For example, unless I have reason to use a specialized data structure, I use intrusive list and RB-tree implementations, which cuts down on the number of individual allocations many fold. Once I allocate something like a request context, I know that I can add it to various lists and lookup trees without having to worry about allocation failure. Most of my projects have more points where they do I/O operations than memory allocations. Should people just ignore whether their reads or writes failed, too?
    - lokedhs 7y ago
      The JVM, and any other runtime which allocates its heap up front. You could argue that's cheating, but it does give you predictable behaviour.
deleted 7y ago
[deleted]

by enneff 7y ago

AnIdiotOnTheNet 7y ago

At least you can then properly blame the software for doing the wrong thing and potentially patch it. The kernel should not implement global behavior that encourages improper memory allocation failure handling.

AgentOrange1234 7y ago
Yes so much. The overcommit approach seems to be to say, “Most people are lazy so we shouldn’t allow anyone to brush their teeth.” Handling malloc failures isn’t rocket science.
- pcwalton 7y ago
  Incorrectly handling malloc failures has been responsible for a lot of security problems. We are all better off acknowledging that C programmers are broadly incapable of writing correct OOM handling at scale and figuring out what to do with this fact, instead of wishing that it weren't this way.
- the_why_of_y 7y ago
  Do you have an example of a nontrivial user-space project that has malloc failure handling that actually works, with tests and all? The one I'm aware of is SQLite. Then there is DBus, whose author disagrees with your assessment. https://blog.ometer.com/2008/02/04/out-of-memory-handling-d-bus-experience/ https://blog.ometer.com/2008/02/04/out-of-memory-handling-d-...
  - wahern 7y ago
    Lua, various OS kernels Like any aspect of writing software, how you approach the problem effects the complexity of the final product. If someone doesn't make a habit of handling OOM, then of course their solutions are going to be messy and complex; they're going to "solve" the problem in the most direct and naive way, which is rarely the best way. For example, unless I have reason to use a specialized data structure, I use intrusive list and RB-tree implementations, which cuts down on the number of individual allocations many fold. Once I allocate something like a request context, I know that I can add it to various lists and lookup trees without having to worry about allocation failure. Most of my projects have more points where they do I/O operations than memory allocations. Should people just ignore whether their reads or writes failed, too?
  - lokedhs 7y ago
    The JVM, and any other runtime which allocates its heap up front. You could argue that's cheating, but it does give you predictable behaviour.

deleted 7y ago

[deleted]