<div dir="ltr">I've done some more debugging on this topic.<div><br><div>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.</div><div><br></div><div>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.</div></div><div>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.</div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I think that this Resize call il wrong because the array lenght is correct before this reduction.</div><div>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. </div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Thank you</div><div><br></div><div>Alessandro</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 15, 2016 at 10:54 PM, David E DeMarle <span dir="ltr"><<a href="mailto:dave.demarle@kitware.com" target="_blank">dave.demarle@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_quote">On Thu, Dec 15, 2016 at 4:39 PM, David E DeMarle <span dir="ltr"><<a href="mailto:dave.demarle@kitware.com" target="_blank">dave.demarle@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"> fails on windows </blockquote></div><div class="gmail_extra"><br>some of the time. ;)</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So something about the read in of the connectivity data has an uninitialized/misaligned word somewhere.</div><span class=""><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra"><div class="m_-9090591967796401783gmail_signature" data-smartmail="gmail_signature">David E DeMarle<br>Kitware, Inc.<br>R&D Engineer<br>21 Corporate Drive<br>Clifton Park, NY 12065-8662<br>Phone: 518-881-4909</div></div><div class="gmail_extra">
</div></span></div>
</blockquote></div><br></div>