[Kst] memory checks...
staikos at kde.org
Wed May 26 20:33:59 CEST 2004
On May 26, 2004 13:27, Andrew Walker wrote:
> At present kst is compiled with the -fno-check-new flag.
> If a memory allocation (new) fails due to lack of memory then
> the std::badalloc exception is thrown. As no exceptions are
> handled in Kst the program will crash in a most ungraceful
Do you have concrete instances of this happening in practice? Do they not
fall into the category of "tried to load way more data than the user has
memory for"? What other concrete cases are there? There are the theoretical
"OS failure" sorts of errors, but what else is there? Those errors are far
too infrequent to justify this additional work of checking all possible
mallocs. In addition, none of the libraries we use are compiled like that.
This means that our mouse likely places of failure will never actually be
checked for error. Why are they most likely? Because most users are using
Linux, and Linux overcommits memory. You don't find out you're in trouble
until you're too far in the hole to get out. Here is a most likely scenario:
malloc(some_big_vector); -> succeeds
malloc(some_vector_we_don't_have_space_for); -> succeeds due to overcommit
<swap hell ensues>
KMessageBox::warning('Please give that vector a new name')
We can't prevent that.
> We could either catch these exceptions, or alternatively,
> could compile with the -fcheck-new flag. This flag will result
> in new not throwing an exception, but will instead return NULL
> for the allocated memory. Kst would then only need to check the
> returned pointer on each memory allocation.
And is not portable.
> Yet another alternative would be to use new (nothrow). However,
> this was added only relatively recently to g++, so may not be
> available to many people.
Correct. It's also not portable.
> Performing these memory checks could allow us to survive in low
> memory conditions when we request a potentially very sizeable
> memory allocation for a new vector. If the allocation fails we
> would advise the user and Ksy would continue to run, whereas at
> present it will simply crash.
Does anyone use Kst in low memory conditions?
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the Kst