3 ms·

Why? Would you also abort on other resource allocation errors, such as opening a socket, or creating a process wide mutex or whatever? I mean sometimes for som

Why? Would you also abort on other resource allocation errors, such as opening a socket, or creating a process wide mutex or whatever? I mean sometimes for some apps aborting on such errors (on some embedded platforms where they must work within specific resource constraints) can be an OK strategy but in general people seem to have this special idea about "bad alloc" conditions. The usual misconceptions are that a) it cannot happen and b) nothing can be done. Both are false.

bluGill 9y ago
If the system is out of memory there isn't much you can do. The general answer is you don't run out of memory in the first place. Linux will kernel panic in similar situations and you are done there too. (in most cases linux unwinds. fails the operation, and continues; but there cases where the only thing left to do is panic and halt)
- Jach 9y ago
  I heard Lisp machines would just stop everything and give you a REPL so you have a chance to clean things up, or just reboot. I don't see why modern systems can't reserve some amount of memory for such a recovery process. In my Linux experience I'm either saved by the OOM Killer (which is dubious 'safety' at best) or the system just hardlocks and I have to either REISUB or sometimes force a power off.
- lispm 9y ago
  On a Symbolics Lisp Machine one lands in a low-level command loop, adds more virtual memory (swapping space on some disk) and then can continue from there.
jerf 9y ago
"Would you also abort on other resource allocation errors, such as opening a socket, or creating a process wide mutex or whatever?" You seem to believe this is not a common choice? I've seen plenty of programs crash on being unable to open a socket/file. I'm not saying this is a good thing, just that your rhetorical implication that it is unusual seems misplaced. And it's not always even that bad. It is true that something can be done, yes, but that something often requires massive fundamental rearchitecting of the core paradigm of the system or something. In most modern languages it isn't that easy to try to deal with resources problems. Erlang could probably do it, and... uhh... I'm already running out of possibilities here.
malkia 9y ago
If you can't allocate a socket, can your app work (game in offline mode)? If you can't allocate memory, can your app work (... example ...)? I guess something like trying to load a huge file (say spreadsheet) in excel-type of app.
smelterdemon 9y ago
Can you give an example of how one could recover from a bad alloc (especially in a "bare metal" situation where you probably can't move anything to disk)?
- maccard 9y ago
  It's contrived, but; imagine a mark and sweep garbage collector. Instead of freeing memory, you mark it as free-able. When you get a bad alloc you an then sweep and actually free the resources, and retry the allocation. A more realistic example might be if you have an application that allocates a large chunk of memory up front for processing later. If it fails, you can stall until a point where you know the memory will be available, or you could retry with a smaller allocation.
ensiferum 9y ago
@malkia, jerf, smeterdemon bluGill Ok first thing first. Like I said for some specicial resource constrained system abort() can be a viable solution, or if you just don't want to deal with any resource allocation failures. In general though if you have a std::vector and a push_back throws bad_alloc, that bad_alloc really only pertains to that particular vector using that particular allocator. If you assume that a bad_alloc coming from anywhere indicates some kind of system/process wide condition you're assuming too much. UNLESS you've designed the system, i.e. in this case the allocators and such and know this assumption to be true, otherwise no. Additionally consider a case where your code is for example reading some data off a disk in a loop and the Nth iteration and push_back throws, the stack is unwound, the vector is destroyed and the memory it consumed before is released. In a "normal" application the bad_alloc can propagate up the stack until it's handled by whatever strategy that the application uses for general resource failures. The two takeaways here are that bad_alloc doesn't really indicate any system wide condition (unless you know that it does), so don't assume such. Secondly bad_alloc is just like any other resource allocation failure. If your application aborts() when it cannot open a socket, that's fine. But if it doesn't, then why would it abort on memory allocation failure? And I really want to stress here that bad_alloc doesn't mean same as OOM for example from the kernel's perspective. It really only pertains to a particular allocator, UNLESS you KNOW otherwise.

bluGill 9y ago

If the system is out of memory there isn't much you can do. The general answer is you don't run out of memory in the first place. Linux will kernel panic in similar situations and you are done there too. (in most cases linux unwinds. fails the operation, and continues; but there cases where the only thing left to do is panic and halt)

Jach 9y ago
I heard Lisp machines would just stop everything and give you a REPL so you have a chance to clean things up, or just reboot. I don't see why modern systems can't reserve some amount of memory for such a recovery process. In my Linux experience I'm either saved by the OOM Killer (which is dubious 'safety' at best) or the system just hardlocks and I have to either REISUB or sometimes force a power off.
lispm 9y ago
On a Symbolics Lisp Machine one lands in a low-level command loop, adds more virtual memory (swapping space on some disk) and then can continue from there.

jerf 9y ago

"Would you also abort on other resource allocation errors, such as opening a socket, or creating a process wide mutex or whatever?" You seem to believe this is not a common choice? I've seen plenty of programs crash on being unable to open a socket/file. I'm not saying this is a good thing, just that your rhetorical implication that it is unusual seems misplaced. And it's not always even that bad. It is true that something can be done, yes, but that something often requires massive fundamental rearchitecting of the core paradigm of the system or something. In most modern languages it isn't that easy to try to deal with resources problems. Erlang could probably do it, and... uhh... I'm already running out of possibilities here.

malkia 9y ago

If you can't allocate a socket, can your app work (game in offline mode)? If you can't allocate memory, can your app work (... example ...)? I guess something like trying to load a huge file (say spreadsheet) in excel-type of app.

smelterdemon 9y ago

Can you give an example of how one could recover from a bad alloc (especially in a "bare metal" situation where you probably can't move anything to disk)?

maccard 9y ago
It's contrived, but; imagine a mark and sweep garbage collector. Instead of freeing memory, you mark it as free-able. When you get a bad alloc you an then sweep and actually free the resources, and retry the allocation. A more realistic example might be if you have an application that allocates a large chunk of memory up front for processing later. If it fails, you can stall until a point where you know the memory will be available, or you could retry with a smaller allocation.

ensiferum 9y ago

@malkia, jerf, smeterdemon bluGill Ok first thing first. Like I said for some specicial resource constrained system abort() can be a viable solution, or if you just don't want to deal with any resource allocation failures. In general though if you have a std::vector and a push_back throws bad_alloc, that bad_alloc really only pertains to that particular vector using that particular allocator. If you assume that a bad_alloc coming from anywhere indicates some kind of system/process wide condition you're assuming too much. UNLESS you've designed the system, i.e. in this case the allocators and such and know this assumption to be true, otherwise no. Additionally consider a case where your code is for example reading some data off a disk in a loop and the Nth iteration and push_back throws, the stack is unwound, the vector is destroyed and the memory it consumed before is released. In a "normal" application the bad_alloc can propagate up the stack until it's handled by whatever strategy that the application uses for general resource failures. The two takeaways here are that bad_alloc doesn't really indicate any system wide condition (unless you know that it does), so don't assume such. Secondly bad_alloc is just like any other resource allocation failure. If your application aborts() when it cannot open a socket, that's fine. But if it doesn't, then why would it abort on memory allocation failure? And I really want to stress here that bad_alloc doesn't mean same as OOM for example from the kernel's perspective. It really only pertains to a particular allocator, UNLESS you KNOW otherwise.