Crash in SignedMaurerDistanceMapImageFilter when aborting

Engineering
1

Hi all,

I am trying to track down a crash I am seeing when aborting SignedMaurerDistanceMapImageFilter while it is generating a distance map. The crash occurs at line 299 in itkImageSource.hxx, ThreaderCallback() :

ThreadIdType total = str->Filter->SplitRequestedRegion(threadId, threadCount, splitRegion);

The issue is that the Filter smart pointer is pointing to nullptr at this point, therefore causing a crash.

I have tracked this down to the clear up code in the PoolMultiThreader class, SingleMethodExecute() function. The ProcessAborted exception is caught (line 110), and the threads are then waited on to ensure they have all terminated. The issue, I believe is that if any of the remaining threads also throw an exception (likely to be ProcessAborted) during this clear up process, it is re-thrown (line 123) meaning that any remaining threads are not waited for.

In SignedMaurerDistanceMapImageFilter::GenerateData(), the ThreadStruct is allocated on the stack, meaning that when the exception gets to this level, the variable str goes out of scope and therefore its Filter member is cleared up. I believe this leads to the crash in ImageSource as any threads still running will attempt to access the Filter member (and the now out of scope and destructed str variable).

I have commented out the throw on line 123 of itkPoolMultiThreader.cxx and rebuilt ITK to check my theory and this change does seems to solve the problem. Does anyone have any thoughts on this? Is this the best solution to this or is there a better one?

I am using ITK 5.0.1 and the machine I am running on is a 12 core hyperthreaded AMD Ryzen so there will potentially be a lot of thread pool threads running concurrently which may cause the issue to show more easily.

Thanks in advance for any ideas,
Ian Lindsay

1 Like
2

Hello,

Thank you for reporting this issue. I was just fixing an Abort test in SimpleITK whose behavior has changed with ITKv5. I’m looking into this, but this looks like a bug report which should be done on Github:https://github.com/InsightSoftwareConsortium/ITK/issues

If you have a short bit or code to reproduce the problem, then it’s much more likely some one can tackle the problem with available time.

1 Like
3

Of course, even better is if you submit a PR which solves the problem.

1 Like
4

Thanks for the replies, I have raised issue #1437 for this. Regarding a PR to resolve the problem, my fix was to simply comment out the throw on line 123 of itkPoolMultiThreader.cxx, however it is probably worth someone with more knowledge of the potential knock-ons reviewing this as this is presumably quite a core part of ITK.

1 Like