# vtkArray constructors or initializers try to free something and fail **URL:** \ **Category:** Development\ **Created:** [July 20, 2020, 8:31am UTC](https://discourse.vtk.org/t/vtkarray-constructors-or-initializers-try-to-free-something-and-fail/3810 "2020-07-20T08:31:41Z")\ **Posts on this page:** 3\ **Page:** 1

**Author:** ![hugo-manet](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/h/96bed5/32.png) [@hugo-manet](https://discourse.vtk.org/u/hugo-manet)\ **Post date:** [July 20, 2020, 8:31am UTC](https://discourse.vtk.org/t/vtkarray-constructors-or-initializers-try-to-free-something-and-fail/3810/1 "2020-07-20T08:31:41Z")

(copy-paste of [https://gitlab.kitware.com/vtk/vtk/-/issues/17962](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 `vtkMultiBlockDataSet`s containing `vtkUnstructuredGrid`s 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 : ```auto [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::~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 : ```auto [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::~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 ---

**Author:** ![cory.quammen](https://discourse.vtk.org/user_avatar/discourse.vtk.org/cory.quammen/32/6751_2.png) [@cory.quammen](https://discourse.vtk.org/u/cory.quammen)\ **Post date:** [July 20, 2020, 1:55pm UTC](https://discourse.vtk.org/t/vtkarray-constructors-or-initializers-try-to-free-something-and-fail/3810/2 "2020-07-20T13:55:53Z")

It looks like the object is being `free`'d twice. Some causes that could lead to double `free`ing: - 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. ---

**Author:** ![hugo-manet](https://discourse.vtk.org/letter_avatar_proxy/v4/letter/h/96bed5/32.png) [@hugo-manet](https://discourse.vtk.org/u/hugo-manet)\ **Post date:** [July 20, 2020, 6:07pm UTC](https://discourse.vtk.org/t/vtkarray-constructors-or-initializers-try-to-free-something-and-fail/3810/3 "2020-07-20T18:07:59Z")

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 `vtkSmartPointer`s, and I give them to `vtkMultiBlockDataSets` through `SetBlock`s. 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.