[Paraview] Fwd: Segfault reading polyhedral cells xdmf3 file
David E DeMarle
dave.demarle at kitware.com
Tue Jan 10 16:20:55 EST 2017
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/20170110/3a57b824/attachment.html>
More information about the ParaView
mailing list