itkApproximateSignedDistanceMapImageFilterTest1 failures

blowekamp · May 9, 2018, 5:35pm

The following test has sporadic failures:
https://open.cdash.org/testDetails.php?test=650830714&build=5365233

They occur more one highly multi-threaded system.

I narrowed the failure down to the IsoContourDistanceImageFilter by setting this filter to only having 1 thread in the above filter’s composite mini-pipeline.

I believe that I further narrowed it down to the following line:

github.com

InsightSoftwareConsortium/ITK/blob/64703c6df3253ca4a0b282747a11473e7dc2bcc7/Modules/Filtering/DistanceMap/include/itkIsoContourDistanceImageFilter.hxx#L383




    PixelRealType valNew0 = val0 * val;
    PixelRealType valNew1 = val1 * val;


    if ( std::fabs( static_cast< double >( valNew0 ) ) < std::fabs( static_cast< double >( outNeigIt.GetNext(n, 0) ) ) )
      {
      outNeigIt.SetNext( n, 0, static_cast< PixelType >( valNew0 ) );
      }
    if ( std::fabs( static_cast< double >( valNew1 ) ) < std::fabs( static_cast< double >( outNeigIt.GetNext(n, 1) ) ) )
      {
      outNeigIt.SetNext( n, 1, static_cast< PixelType >( valNew1 ) );
      }
    }
  else
    {
    itkExceptionMacro(<< "Gradient norm is lower than pixel precision");
    }
  } // end if (sign != signNeigh)
}   //end for n
}

Which appear to be writing outside the output region for the thread leading to race conditions. I could not find a quick solution to it, and have moved on at the moment.

Any one else care to pick this up?

blowekamp · May 24, 2018, 3:25pm

Here is my oafish solution to the concurrent read/write in the output of the filter:
http://review.source.kitware.com/#/c/23467/