I’ve discovered a bug that is probably 2 bugs in one when slicing a 3D scalar field using vtkCutter using the plane implicit function point=(0,0,0) normal=(0,0,1) with vtkContour that causes it to throw an SEHexception.

I’m using VTK 8.1.1.

Summary of issues:

- vtkBoundingBox::ComputeDivisions() is not robust with very small bounding box lengths
- Is there a numerical error (rouding, precision, etc) problem with vtkCutter?

I traced the code and found the problem to be an extremely large memory allocation done in

`vtkPointLocator::InitPointInsertion()`

at line 1191 of vtkPointLocator.cxx

`this->HashTable = new vtkIdListPtr[this->NumberOfBuckets];`

because NumberofBuckets=4,342,286,870,571

Digging a little deeper, I found that

`vtkBoundingBox::ComputeDivisions()`

handles 0 bounding box dimension length (X, Y or Z), but not very small values close to 0, such as

`4.4408920985006262e-16`

in Z. The other dimension lengths are LengthX=40 and LengthY=30.

This causes a division in ComputeDivisions() to produce a very large number (I won’t get into the details), which eventually produces the large value for NumberOfBuckets.

This can be fixed easily by snapping values of the length to 0 after calling this->GetLengths(lengths) (line 436) and before the look checking for 0 length (line 438) like this:

`const relative_tolerance= this->GetMaxLength()*1e-10; (is there an absolute VTK tolerance defined?)`

`for (int i=0; i<3; ++i)`

`{`

`if (lengths[i] <= relative_tolerance)`

`lengths[i]= 0;`

`}`

This would certainly make the code in ComputeDivisions() more robust.

Has anyone seen this before and has a similar fix already been submitted?

But the second (and stranger) bug is why am I getting points off of the Z=0 plane at all?

According to the bounding box of the points, I’m getting a point with a MinZ at -2.2204460492503131e-16 and a MaxZ at 2.2204460492503131e-16.

Is there a precision problem with vtkCutter?

Thanks.