I can reproduce this by:

• download sample DTI
• change to Red Slice Only mode

The crash happens inside the threaded routines of vtkImageResliceMask, at the last line below:

vtkImageData backgroundMask = outData[1];
// Get the output pointer
void outPtr = outData[0]->GetScalarPointerForExtent(outExt);
void *backgroundMaskPtr = outData[1]->GetScalarPointerForExtent(outExt);

here, outData[1]'s extent is not the same as outData[0] - that is, the first call to GetScalarPointerForExtent works, but the second one does not.

vtkImageResliceMask is the class that Ramundo Sierra added several years ago, and it may never have been reviewed for correctness of the pipeline with the latest VTK (or, perhaps, the multi-output feature of the VTK pipeline now has a bug in it that wasn't in earlier VTKs - or perhaps we we're not setting up the pipeline correctly in response to resize events).

It is ok to have a different extent as long as the backgroundmask extent contains the outData[0] extent.
outData[0] extent is pipeline controlled (the end of the pipeline requires a specific extent which gets propagated to the filter), however the backgroundmask extent is always the full size of the volume and doesn't depend on the display.

BTW, the same issue happens with non-dti data (just load data, switch the layout to, for example, red slice only mode).

Fixed in r17840:
http://viewvc.slicer.org/viewvc.cgi/Slicer4?view=revision&revision=17840

Solution is to ensure we use a correct demand driven data pipeline. Problem was present since r17397.

The problem with other (not DTI) images is different and is a much more recent bug introduced by r17798.