[Bf-committers] memory allocation and crashes

[Joe Eagar]

Stephan wrote:
> On Tue, 2007-01-30 at 15:59 -0700, Joe Eagar wrote:
>   
>> Tom M wrote:
>>     
>>> Would it be possible to change trying to allocate too much memory to
>>> keep it from crashing?
>>>
>>> If you are sculpting at a high level - pressing tabkey by accident can
>>> crash you since editmode uses more ram than sculpt mode.  Or if you
>>> accidentally add a level when you meant to change back to a higher
>>> level you had already created.
>>>
>>> Both of those have happened to me more than once alas, and I know
>>> other users have had similar occurences.
>>>
>>> LetterRip
>>>       
>> Shouldn't be hard, just a matter of checking for NULL on entering 
>> editmode, then exiting if memory can't be allocated and throwing an 
>> error.  Or perhaps editmode could allocate in fixed-size blocks of 
>> memory.  Is this important for release do you think? Could be kindof 
>> iffy figuring out the best way to deal with it.
>>
>> One thing that might be good would be to write a SIGSEGV handler that 
>> saves the undo buffer on crashes.   I think you'd have to write a 
>> special function in guardedalloc where it  would use a special 
>> pre-allocated "crash-safe" pool of memory if malloc returned NULL.  Then 
>> all the file writing code would use this for allocation.
>>
>> Joe
>>     
>
>   
I said "undo buffer" this is much less likely to be corrupt :)

I actually implemented this myself once.  It was cool.
> But the memory might be corrupt after SIGSEGV !?
> The urgent problem is when alloc of huge memory blocks fails. And
> if that goes wrong you still have enough memory for cleanup and
> file-writing.
> So the parts of code that allocate a lot of memory could check,
> cleanup, emergency-save and exit with a error-message.
>
>   

Joe