[Paraview] Fwd: Segfault reading polyhedral cells xdmf3 file

[Alessandro De Maio]

I've done some more debugging on this topic.

The problem is not related only to windows machines: the easy example that
I attached at the beginning of this post (polyhedron.xmf) seems to be
correctly opened on Linux machines, but if you try to reopen it several
times (for example using the new 5.2 feature of "Reload Files"), not very
often but sometimes it gives segfault also on Linux machines. Moreover, if
you try to open a bigger file (with more polyhedra inside) it fails more
often or, sometimes, it seems not to read all the polyhedral cells in the
mesh.

I've tried to investigate the code and I think I've found the reason of
this behaviour, but of course, as I'm not an expert in VTK programming, a
more relevant opinion from the experts in this forum would be appreciated.
The function that builds the VTK topology starting from what has been read
from a xmdf file is vtkXdmf3DataSet::CopyShape in the source file
 vtkXdmf3DataSet.cxx (path superbuild/paraview/src/VTK/IO/Xdmf3/ in the
5.2.0 superbuild building directory). In case of "mixed" XdmfTopologyType
(line 1460 of the file) it creates a vtkCellArray structure named vCells
that at line 1548 is passed to the SetCells function to create the
connectivity information of the DataSet. This vCells structure is filled
through the pointer *cells_ptr that is initially dimensioned with a size
equal to conn_lenght (line 1470) that is the size of the topology array
xTopology that comes form xdmf file reading.
This structure is filled as a sequence of blocks: each block for each cell.
If the cell is not a polyhedron it contains the number of points for that
cell followed by the list of pointID of the vertices. If the cell is a
polyhedron, as it's explained at lines 1531-1534, the cell information is
the sequence of: cell Lenght (that is the size of the following list for
that cell), the number of faces and, for each face, the number of points
and the list of points. So this array is exactly the same of the one that
has been read from the xdmf file, with the substitution of the cell type
for non polyhedral cells with the number of points for that cell, and, with
the substitution of the cell type with the cell lenght for polyhedral cells.

But, after the loop on cells to fill this structure, at line 1547 there is
a call to the function Resize to reduce the Array to an overall lenght
index-sub where index is the original array lenght and sub is the number of
polyhedral cells.

I think that this Resize call il wrong because the array lenght is correct
before this reduction.
If you print the content of the vCell structure after the Resize, for the
example of polyhedron.xmf, the last two elements of the array (that are the
last two nodes of the last hexaedron cell of the mesh) are missing.

Probably when the SetCells function is called at line 1548 with a cell_type
array of the right lenght but a truncated vCells array as the second
argument, the missing elements of vCell array "could" be available  as they
should be next in memory to the truncated array, but this is not guaranteed
because it is randomical and it depends on the operating system (that could
explain the different behaviour between linux and windows).

In any case I've tried to comment the Resize function call and the xmdf
reader has been able to read all the cases that I've tried to read with
polyhedral and not polyhedral 3d cells (there is still a problem with
polygons but I'll write another post on this topic).

As I've said at the beginning of this too much long message, I hope that
VTK/Paraview developers give their opinion about my hypothesis.

Thank you

Alessandro


On Thu, Dec 15, 2016 at 10:54 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

>
> On Thu, Dec 15, 2016 at 4:39 PM, David E DeMarle <dave.demarle at kitware.com
> > wrote:
>
>> fails on windows
>
>
> some of the time. ;)
>
> If you open it up with the spreadsheet view (so no rendering), you can see
> that the cell connectivity array gets nonsense in it - some of the time.
> When you then open a renderview and show it, it crashes.
>
> So something about the read in of the connectivity data has an
> uninitialized/misaligned word somewhere.
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20161216/1f081a46/attachment.html>