[vtk-developers] Memory Management & Exception Handling in VTK

Brad King brad.king at kitware.com
Tue Apr 12 11:51:01 EDT 2005


Randall Hand wrote:
> I had expected VTK to simply print an error, generate a garbage image, 
> and go about it's business.  What actually happens is a coredump.  I've 
> discovered that in Common/vtkDataArrayTemplate.txx, all of the arrays 
> are allocated through "new", and subsequently checked to make sure they 
> aren't NULL.  While this works for "mallocs", most alot of C++ 
> implementations (including the MipsPro version on these SGI's) raise a 
> "bad_alloc" exception instead.  I made the required changes (patch 
> attached to see the changes) to do the same thing as the null checks 
> through Try/Catch blocks but I'm saddened to see that it still doesn't work.

You are correct.  That code was written before any compilers implemented 
exceptions and then was cut-and-paste into its current location.  I've 
applied a slightly modified version of your patch and committed the 
changes.  The bad_alloc exception will now be caught properly.

> Alot of the functions, like Allocate, return 1 on success and 0 on 
> failure.  Unfortunately, I can't see these return values ever being 
> used.  Also, alot of these functions make invalid assumptions about 
> things working, most notably vtkDataArrayTemplate::WritePointer.  This 
> function returns (this->Array + id), whether this->Array is NULL or 
> valid.  This causes later segfaults if any of the Resize or Allocate 
> functions failed to allocate the memory.

We are aware of such problems but they are unfortunately not a high 
priority.  It is still possible to handle very large data with VTK but 
it is up to the application to enable the streaming features to avoid 
allocating more memory than is available.

-Brad



More information about the vtk-developers mailing list