Debugging application crash

Support
1

I am in process of merging our organization’s SW pipeline based on top of Slicer-4.11 into Slicer-5.10. While I am able to merge and resolve merge conflicts, my application is crashing on startup. I was following the startup routines from,



qSlicerApplicationHelper::postInitializeApplication

if (enableMainWindow)
{
window.reset(new SlicerMainWindowType); <----
}

So far I am able to trace the crash until this function, this→Modified() call:

//----------------------------------------------------------------------------
void vtkMRMLSliceLogic::SetSliceNode(vtkMRMLSliceNode* newSliceNode)
{
  if (this->SliceNode == newSliceNode)
  {
    return;
  }

  // Observe the slice node for general properties like slice visibility.
  // But the slice layers will also notify us when things like transforms have
  // changed.
  // This class takes care of passing the one slice node to each of the layers
  // so that users of this class only need to set the node one place.
  vtkSetAndObserveMRMLNodeMacro(this->SliceNode, newSliceNode);

  this->UpdateSliceCompositeNode();

  for (LayerListIterator iterator = this->Layers.begin(); iterator != this->Layers.end(); ++iterator)
  {
    vtkMRMLSliceLayerLogic* layer = *iterator;
    if (layer != nullptr)
    {
      layer->SetSliceNode(newSliceNode);
    }
  }

  this->Modified();   <----
}

I further traced this to this function:

//---------------------------------------------------------------------------
void vtkMRMLAbstractLogic::Modified()
{
  if (this->GetDisableModifiedEvent())
  {
    ++this->Internal->ModifiedEventPending;
    return;
  }
  this->Superclass::Modified();
}

I understand this→Superclass::Modified() is a call routines connected to observers. But I am not able to find what routines this caller calls which is causing the crash. Some hints I was able to find were,

1- It crashes on setting first vtk MRML slice node ‘Red’.

2- I believe the invoke event that triggers crash is vtkCommand::ModifiedEvent. I find this in vtkObject clas, function, vtkTypeBool vtkSubjectHelper::InvokeEvent(unsigned long event, void* callData, vtkObject* self) in call elem->Command->Execute(self, event, callData);. The event# is 33.

I wanted to ask is there a way to find what routines the callback calls that can be checked for possible crash.

2

Have you hooked up a debugger to get a stack trace? The observer pattern means that code dynamically adds callback functions to be called when data is modified, and from there many things can happen and your code needs to be careful not to get in an event loop or work with data that isn’t yet fully configured.

3

Hi Pieper, I am thinking to hookup debugger but currently I am in release mode so will have to build in debug mode. For now, is there any way to know which functions are using callback for a ModifiedEvent, it should be statically defined (hardcoded) instead of dynamic?

4

Update on this. I was able to use stack trace and fix the problem. Thank you Pieper for the idea. Closing this thread.

5

That’s a tough one to track down, especially when it’s an intermittent crash. Since there’s no clear error message, it usually points toward a memory management issue or a conflict with a specific module. A good first step is to check the Slicer log files right after a crash happens - sometimes the very last entry gives a hint of what was being loaded. If you’re on Windows, you might also want to try running Slicer through a debugger like Visual Studio to see if you can catch the specific exception. Sometimes just disabling any recently added extensions one by one can help narrow down if a specific tool is causing the instability. Stay patient, these debugging marathons can be a real test!

6

Hi @Nancy_Casper Thank you for the response. I was able to track down using stack trace as suggested by Pieper.