3 ms·

> People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation Really d

> People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation Really depends on the field. I heard more than once in my life now that it's better to reboot every night than spend even an afternoon of engineering trying to fix memory leaks.

outworlder 3y ago
That's good when it's just about memory leaks. Your missile guidance code can have leaks as long as the missile completes the mission, since it will all be... "garbage collected" anyway. It's not great when you have problems like use after free and pointers going to where they don't belong. Those can cause security vulnerabilities that rebooting won't fix.
- hajile 3y ago
  Then they make a version that flies farther and it sometimes randomly fails to detonate.
  - toast0 3y ago
    So you write a note mentioning there's a leak, and debug it if there's a need for it. Finding a bug doesn't mean you need to fix it, or fix it right away. Using Rust doesn't preclude resource leaks. I'm pretty sure I've managed to run into resource leaks in all of the languages I've used in production, doesn't matter if they were managed or not. Sometimes limiting the lifetime of the thing that holds resources, and let process (or system) death clean it up works great; sometimes that's terrible, depends on the cost of death/restart, the lifetime between deaths, human intervention required, accuracy of lifetime estimation method, probably some other things. I don't worry too much about leaks that require a restart every year or so; nor would I worry about a leak in a missile that will cause issues beyond the achievable maximum flight time.
kevin_thibedeau 3y ago
MongoDB's BSON library calls abort() on malloc failure because they can't be bothered to handle OOM gracefully.
- tialaramex 3y ago
  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.
  - jeff-davis 3y ago
    Postgres is designed to recover on OOM in most cases.
    - tialaramex 3y ago
      That's nice, how well does it work in practice?
      - jeff-davis 3y ago
        It works. Bugs have been found, and some more bugs probably exist, but I think it meets a fairly high bar of quality.
- throwaway234890 3y ago
  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.

outworlder 3y ago

That's good when it's just about memory leaks. Your missile guidance code can have leaks as long as the missile completes the mission, since it will all be... "garbage collected" anyway. It's not great when you have problems like use after free and pointers going to where they don't belong. Those can cause security vulnerabilities that rebooting won't fix.

hajile 3y ago
Then they make a version that flies farther and it sometimes randomly fails to detonate.
- toast0 3y ago
  So you write a note mentioning there's a leak, and debug it if there's a need for it. Finding a bug doesn't mean you need to fix it, or fix it right away. Using Rust doesn't preclude resource leaks. I'm pretty sure I've managed to run into resource leaks in all of the languages I've used in production, doesn't matter if they were managed or not. Sometimes limiting the lifetime of the thing that holds resources, and let process (or system) death clean it up works great; sometimes that's terrible, depends on the cost of death/restart, the lifetime between deaths, human intervention required, accuracy of lifetime estimation method, probably some other things. I don't worry too much about leaks that require a restart every year or so; nor would I worry about a leak in a missile that will cause issues beyond the achievable maximum flight time.

kevin_thibedeau 3y ago

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

tialaramex 3y ago
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.
- jeff-davis 3y ago
  Postgres is designed to recover on OOM in most cases.
  - tialaramex 3y ago
    That's nice, how well does it work in practice?
    - jeff-davis 3y ago
      It works. Bugs have been found, and some more bugs probably exist, but I think it meets a fairly high bar of quality.
throwaway234890 3y ago
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.