[Paraview] Fwd: Segfault reading polyhedral cells xdmf3 file

[Alessandro De Maio]

Hi David,
     thank you for the correction. It should solve the problem. Without
increasing sub it will remain 0 and the Resize call does nothing.

A.

On Tue, Jan 10, 2017 at 10:20 PM, David E DeMarle <dave.demarle at kitware.com>
wrote:

> Thanks Allesandro.
>
> From your long message ;), I think that the fix then is to not overcount
> the space taken for the polyhedral cells. https://gitlab.kitware.
> com/vtk/vtk/merge_requests/2346
>
> thoughts?
>
>
> David E DeMarle
> Kitware, Inc.
> R&D Engineer
> 21 Corporate Drive
> Clifton Park, NY 12065-8662
> Phone: 518-881-4909 <(518)%20881-4909>
>
> On Fri, Dec 16, 2016 at 11:11 AM, Alessandro De Maio <demaio.a at gmail.com>
> wrote:
>
>> 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 <(518)%20881-4909>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20170111/d62e098b/attachment.html>