[Bf-committers] memory allocation and crashes

Stephan stapfx at gmx.de
Wed Jan 31 03:07:12 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.
> >
> > 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

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.




More information about the Bf-committers mailing list