Re: Exceeding memory while using STL containers
Markus Schoder wrote:
kanze wrote:
Martin Bonner wrote:
Note that failing to throw std:bad_alloc doesn't mean the
STL is failing to adhere to the standard - there is a
general get-out clause for "resource limit exceeded" in the
standard.
It's debatable whether this clause applies when the standard
provides an official means of signaling the error. In practice,
however, when you're out of memory, you also stand a definite
risk of stack overflow when calling operator new. Which is
definitly covered by this clause.
On the other hand, in the older versions of AIX (older, in this
case, being those from more than 8 or 10 years ago), and some
configurations of Linux, the system returns a valid pointer even
when no memory is available; your program (or someone elses!)
then crashes when it attempts to use the pointer. I find it
hard to justify this under the "resource limits exceeded"
clause, because the system has told me that the resource was
there; I'm not trying to use additional resources when it
crashes, but rather resources that I have already successfully
acquired.
This was (not sure wether it still is, but the feature is
definitely still available) the default behaviour of the Linux
kernel.
I think it is still the default behavior of the kernel. Various
distributions, however, may have it disactivated.
It is called memory overcommit. This causes every allocation
to succeed so long as it can be fitted into the address space
of the process regardless of available memory (including
virtual memory). Once you start writing to the memory the
kernel starts mapping pages to physical memory which may fail.
If that happens the out-of-memory killer kicks in and selects
through some heuristics a process to kill. The killed process
never regains control and therefore cannot guard at all
against this. The killed process may not even be the one
causing the out of memory condition in the first place.
I know. I thought that's what I sid.
All of this sounds quite horrible and of course this behaviour
can be switched off however as a matter of fact there are
memory allocation and usage patterns that will work with
overcommit and fail with an out of memory error without
overcommit. So for non critical systems memory overcommit can
be a win.
There are a few very specific application domains where it is
preferable. Offering it can be considered a feature. Silently
implementing it, without telling anyone, and without providing a
means of turning it off (the case originally in both AIX and
Unix) can only be considered... well, I can't think of a word
bad enough for it.
--
James Kanze kanze.james@neuf.fr
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]