[Kst] memory checks...

[Andrew Walker]

To catch every case of a failed memory allocation would involve 
using try catch around every function that performs a memory allocation,
including (presumably) all Qt and KDE code. In my opinion this would
be the ideal situation - programs should not crash under low memory
conditions. I recognize this is a lot of work but it is something that
could be done incrementally.

Failing that, we should at least do a confirmation of the memory 
allocation for major allocations; such as new vectors. 

Requesting a large memory allocation will fail with a std::badalloc
exception thrown. You can test this in code. Just request a buffer
larger than your memory space (including swap).

If portability prevents us from using particular features then we
just ifdef them out in those cases.

People most certainly will use Kst under low memory conditions.
Perhaps not intentionally. Clearly they will not expect Kst to crash,
and will be less than happy if it does.

Andrew

---------- Original Message ----------------------------------
From: George Staikos <staikos at kde.org>
Date:  Wed, 26 May 2004 14:33:59 -0400

>On May 26, 2004 13:27, Andrew Walker wrote:
>> At present kst is compiled with the -fno-check-new flag.
>
>   With gcc...
>
>> 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
>> manner.
>
>   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')
>-> CRASH
>
>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?
>
>-- 
>George Staikos
>KDE Developer			http://www.kde.org/
>Staikos Computing Services Inc.	http://www.staikos.net/
>


________________________________________________________________
$0 Bannerless Web Hosting, 10 POP and Web Email Accounts, & more
Get It Now At www.doteasy.com