vtkArray constructors or initializers try to free something and fail

Development
1

(copy-paste of https://gitlab.kitware.com/vtk/vtk/-/issues/17962)
Hi,
I’m having trouble with some (long) piece of code, part of a Paraview filter (part of the Topology ToolKit project).
That code takes vtkMultiBlockDataSets containing vtkUnstructuredGrids in input, and outputs a big vtkMultiBlockDataSet containing them all.
The codes runs fine most times myClass::RequestData() is called, but sometimes (when a particular dataset is removed from the input), I have the most obscure bug :

[myClass] Complete ...................... [0.008s|4T|100%]
free(): invalid next size (fast)
Loguru caught a signal: SIGABRT
Stack trace:
62      0x55b8b61eac2a paraview(+0x7c2a) [0x55b8b61eac2a]
[...]
12      0x7f124751a179 myClass::RequestData(vtkInformation*, vtkInformationVector**, vtkInformationVector*) + 2473
11      0x7f128e66515b vtkUnstructuredGrid::New() + 27
10      0x7f128e6650d3 vtkUnstructuredGrid::vtkUnstructuredGrid() + 819
9       0x7f128e664d72 vtkUnstructuredGrid::AllocateExact(long long, long long) + 322
8       0x7f128e433db5 vtkCellTypes::Allocate(long long, long long) + 69
7       0x7f128d5e7e39 vtkUnsignedCharArray::~vtkUnsignedCharArray() + 9
6       0x7f128d5e93af vtkAOSDataArrayTemplate<unsigned char>::~vtkAOSDataArrayTemplate() + 31
5       0x7f1296ad8f60 cfree + 1552
4       0x7f1296ad190a /lib/x86_64-linux-gnu/libc.so.6(+0x9090a) [0x7f1296ad190a]
3       0x7f1296aca897 /lib/x86_64-linux-gnu/libc.so.6(+0x89897) [0x7f1296aca897]
2       0x7f1296a81801 abort + 321
1       0x7f1296a7fe97 gsignal + 199
0       0x7f1296a7ff20 /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f1296a7ff20]
(  11.543s) [paraview        ]                       :0     FATL| Signal: SIGABRT

I have tried lots of different filter code configurations and actions inside Paraview, and I can have a wide variety of reasons to fail, but it always boils down to a free() : invalid next size (fast) from the destructor of some vtkArray (in the first example the vtkUnsignedCharArray from the vtkCellTypes, but I can have a vtkIntArray from somewhere random :

[myClass] Complete ...................... [0.009s|4T|100%]
free(): invalid next size (fast)

Loguru caught a signal: SIGABRT
Stack trace:
60      0x55cc53a04c2a paraview(+0x7c2a) [0x55cc53a04c2a]
[...]
17      0x7fa59b2514e9 vtkMultiBlockDataSet::~vtkMultiBlockDataSet() + 9
16      0x7fa59b150bcd vtkDataObjectTree::~vtkDataObjectTree() + 77
15      0x7fa59b377169 vtkUnstructuredGrid::~vtkUnstructuredGrid() + 9
14      0x7fa59b159339 vtkDataSet::~vtkDataSet() + 41
13      0x7fa59b2af387 /usr/local/bin/../lib/libvtkCommonDataModel-pv5.8.so.1(+0x287387) [0x7fa59b2af387]
12      0x7fa59b161447 vtkDataSetAttributes::~vtkDataSetAttributes() + 23
11      0x7fa59b161259 vtkDataSetAttributes::Initialize() + 9
10      0x7fa59b17e242 vtkFieldData::Initialize() + 210
9       0x7fa59b161079 vtkDataSetAttributes::InitializeFields() + 9
8       0x7fa59b17d3e4 vtkFieldData::InitializeFields() + 52
7       0x7fa59a4685a9 vtkIntArray::~vtkIntArray() + 9
6       0x7fa59a4691ff vtkAOSDataArrayTemplate<int>::~vtkAOSDataArrayTemplate() + 31
5       0x7fa5a37ebfd0 cfree + 1552
4       0x7fa5a37e497a /lib/x86_64-linux-gnu/libc.so.6(+0x9097a) [0x7fa5a37e497a]
3       0x7fa5a37dd907 /lib/x86_64-linux-gnu/libc.so.6(+0x89907) [0x7fa5a37dd907]
2       0x7fa5a37948b1 abort + 321
1       0x7fa5a3792f47 gsignal + 199
0       0x7fa5a3792fd0 /lib/x86_64-linux-gnu/libc.so.6(+0x3efd0) [0x7fa5a3792fd0]
(  55.030s) [paraview        ]                       :0     FATL| Signal: SIGABRT

Anyway, this is really random. Why is it that, only with my particular filter, random vtkArrays may fail ?

My configuration :

  • Paraview 5.8.0
  • TTK (up-to-date dev version)
  • Ubuntu 18.04.4 LTS
2

It looks like the object is being free'd twice. Some causes that could lead to double freeing:

  • multiple calls to some VTK object’s Delete() function
  • calling Delete() on a VTK object wrapped in a vtkSmartPointer`

Since this occurs when you are removing a dataset from the input, I would start by looking there for suspicious memory freeing. One strategy could be to remove all calls to Delete() and then add them back one by one. It’s hard to suggest more without seeing the code, but hopefully that gets you started.

3

Thanks for the fast answer !
I suspected something like that, but I don’t actually call Delete() myself.
But all the data I allocate is through vtkSmartPointers, and I give them to vtkMultiBlockDataSets through SetBlocks. Am I somehow supposed to get sure that the data survives after I do this ? Is there some way for me to find out when I can delete those, so that the memory doesn’t leak ?

Is there maybe some documentation or manual on memory management in your API that I overlooked ? It’s quite strange that you have smart pointers mechanisms in the API, but it isn’t used in the function prototypes.

Also, the real strange thing is that the program explodes on a call to New(). Maybe it’s just my compiler optimizing something but I can’t get my head around how that’s possible.