[Bf-committers] memory allocation and crashes
joeedh at gmail.com
Wed Jan 31 09:20:15 CET 2007
> 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.
>> 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.
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
> So the parts of code that allocate a lot of memory could check,
> cleanup, emergency-save and exit with a error-message.
More information about the Bf-committers