Crashes in FEM test suite

About the development of the FEM module/workbench.

Moderator: bernd

StefanBruens
Posts: 24
Joined: Sun Nov 29, 2020 5:30 am

Crashes in FEM test suite

Post by StefanBruens »

I have noted a reproducibe crash in FemTestApp

Code: Select all

import FreeCAD
import unittest
suite = unittest.TestSuite()
suite.addTest(unittest.defaultTestLoader.loadTestsFromName('TestFemApp'))
r = unittest.TextTestRunner(verbosity=2)
r.run(suite)

Code: Select all

LANG=C python3 ./testfem.py 
...
test_00print (femtest.app.test_object.TestObjectCreate) ... ok
test_femobjects_make (femtest.app.test_object.TestObjectCreate) ... Segmentation fault (Speicherabzug geschrieben)
Last known good version is 2022-03-26, githash 83753534b9. Likely first bad version is 2022-03-30 6839d2235d.

The actual crash is in VTKs XML generating code. The problematic call originates from
https://gitlab.kitware.com/vtk/vtk/-/bl ... r.cxx#L112

Code: Select all

#0  0x00007ffff1e66441 in vtkXMLUnstructuredGridWriter::WriteInlinePiece (this=this@entry=0x555555a053b0, indent=...) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLUnstructuredGridWriter.cxx:112
#1  0x00007ffff1e5ba9e in vtkXMLUnstructuredDataWriter::WriteInlineMode (this=0x555555a053b0, indent=...) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLUnstructuredDataWriter.cxx:473
#2  0x00007ffff1e5b9a2 in vtkXMLUnstructuredDataWriter::WriteAPiece (this=0x555555a053b0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLUnstructuredDataWriter.cxx:421
#3  0x00007ffff1e62276 in vtkXMLUnstructuredDataWriter::ProcessRequest (this=0x555555a053b0, request=0x555556466bf0, inputVector=<optimized out>, outputVector=<optimized out>) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLUnstructuredDataWriter.cxx:205
#4  0x00007ffff1368f90 in vtkExecutive::CallAlgorithm (this=0x5555564662f0, request=0x555556466bf0, direction=<optimized out>, inInfo=0x555556467010, outInfo=0x55555645f980) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkExecutive.cxx:746
#5  0x00007ffff1363d19 in vtkDemandDrivenPipeline::ExecuteData (this=0x5555564662f0, request=0x555556466bf0, inInfo=0x555556467010, outInfo=0x55555645f980) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:462
#6  0x00007ffff1361791 in vtkCompositeDataPipeline::ExecuteData (this=0x5555564662f0, request=0x555556466bf0, inInfoVec=0x555556467010, outInfoVec=0x55555645f980) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkCompositeDataPipeline.cxx:162
#7  0x00007ffff136c21d in vtkDemandDrivenPipeline::ProcessRequest (this=0x5555564662f0, request=0x555556466bf0, inInfoVec=0x555556467010, outInfoVec=0x55555645f980) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:261
#8  0x00007ffff13a0379 in vtkStreamingDemandDrivenPipeline::ProcessRequest (this=0x5555564662f0, request=0x555556466bf0, inInfoVec=0x555556467010, outInfoVec=0x55555645f980)
    at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:343
#9  0x00007ffff13a3627 in vtkStreamingDemandDrivenPipeline::Update (this=0x5555564662f0, port=-1, requests=0x0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:417
#10 0x00007ffff1e7718f in vtkXMLWriterBase::Write (this=0x555555a053b0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLWriterBase.cxx:200
#11 0x00007ffff1e219e1 in vtkXMLDataObjectWriter::WriteInternal (this=0x555555f8dda0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLDataObjectWriter.cxx:113
#12 0x00007ffff13a3627 in vtkStreamingDemandDrivenPipeline::Update (this=0x5555564662f0, port=-1, requests=0x0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:417
#13 0x00007ffff1e7718f in vtkXMLWriterBase::Write (this=0x555555a053b0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLWriterBase.cxx:200
#14 0x00007ffff1e219e1 in vtkXMLDataObjectWriter::WriteInternal (this=0x555555f8dda0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLDataObjectWriter.cxx:113
#15 0x00007ffff1e66a08 in vtkXMLWriter::RequestData (this=0x555555f8dda0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLWriter.cxx:574
#16 0x00007ffff1368f90 in vtkExecutive::CallAlgorithm (this=0x55555645fdb0, request=0x555556467ca0, direction=<optimized out>, inInfo=0x555556469dc0, outInfo=0x55555646a2f0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkExecutive.cxx:746
#17 0x00007ffff1363d19 in vtkDemandDrivenPipeline::ExecuteData (this=0x55555645fdb0, request=0x555556467ca0, inInfo=0x555556469dc0, outInfo=0x55555646a2f0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:462
#18 0x00007ffff1361791 in vtkCompositeDataPipeline::ExecuteData (this=0x55555645fdb0, request=0x555556467ca0, inInfoVec=0x555556469dc0, outInfoVec=0x55555646a2f0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkCompositeDataPipeline.cxx:162
#19 0x00007ffff136c21d in vtkDemandDrivenPipeline::ProcessRequest (this=0x55555645fdb0, request=0x555556467ca0, inInfoVec=0x555556469dc0, outInfoVec=0x55555646a2f0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:261
#20 0x00007ffff13a0379 in vtkStreamingDemandDrivenPipeline::ProcessRequest (this=0x55555645fdb0, request=0x555556467ca0, inInfoVec=0x555556469dc0, outInfoVec=0x55555646a2f0)
    at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:343
#21 0x00007ffff13a3627 in vtkStreamingDemandDrivenPipeline::Update (this=0x55555645fdb0, port=-1, requests=0x0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:417
#22 0x00007ffff1e7718f in vtkXMLWriterBase::Write (this=0x555555f8dda0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLWriterBase.cxx:200
#23 0x00007ffff29f3975 in Fem::PropertyPostDataObject::SaveDocFile (this=0x5555563c5140, writer=...) at /usr/include/vtk-9.1/vtkSmartPointer.h:206
#24 0x00007ffff7163718 in Base::ZipWriter::writeFiles (this=this@entry=0x7fffffffa5b0) at /usr/src/debug/FreeCAD-0.20.0~g20220402.027fb07743-0.x86_64/src/Base/Writer.cpp:270
#25 0x00007ffff738134f in App::Document::saveToFile (this=0x555555bf7a20, filename=0x5555563ca5d0 "/tmp/FEM_unittests/objects_create_all_1ef7467b383b/all_objects.FCStd") at /usr/src/debug/FreeCAD-0.20.0~g20220402.027fb07743-0.x86_64/src/App/Document.cpp:2660
#26 0x00007ffff737903e in App::Document::save (this=0x555555bf7a20) at /usr/src/debug/FreeCAD-0.20.0~g20220402.027fb07743-0.x86_64/src/App/Document.cpp:2314
#27 0x00007ffff7379171 in App::Document::saveAs (this=0x555555bf7a20, _file=<optimized out>) at /usr/src/debug/FreeCAD-0.20.0~g20220402.027fb07743-0.x86_64/src/App/Document.cpp:2273
#28 0x00007ffff73fb1b4 in App::DocumentPy::saveAs (this=0x5555563355a0, args=<optimized out>) at /usr/include/c++/11/bits/basic_string.h:194
#29 0x00007ffff73f6a14 in App::DocumentPy::staticCallback_saveAs (self=<App.Document at remote 0x5555563355a8>, args=<optimized out>) at /usr/src/debug/FreeCAD-0.20.0~g20220402.027fb07743-0.x86_64/build/src/App/DocumentPy.cpp:493
...
#46 0x00007ffff7d615b4 in PyEval_EvalFrameEx (throwflag=0, 
    f=Frame 0x555555bdfed0, for file /usr/lib64/python3.8/unittest/case.py, line 1700, in run (self=<TestObjectCreate(_testMethodName='test_femobjects_make', _outcome=<_Outcome(expecting_failure=False, result=<TextTestResult(failfast=False, failures=[], errors=[], testsRun=7, skipped=[], expectedFailures=[], unexpectedSuccesses=[], shouldStop=False, buffer=False, tb_locals=False, _stdout_buffer=None, _stderr_buffer=None, _original_stdout=<_io.TextIOWrapper at remote 0x7ffff7874e10>, _original_stderr=<_io.TextIOWrapper at remote 0x7ffff7874ee0>, _mirrorOutput=False, stream=<_WritelnDecorator(stream=<_io.TextIOWrapper at remote 0x7ffff7874ee0>) at remote 0x7fffeac4d3a0>, showAll=True, dots=False, descriptions=True, _testRunEntered=True, _moduleSetUpFailed=False, _previousTestClass=<type at remote 0x5555558b01a0>) at remote 0x7fffeac4d400>, result_supports_subtests=True, success=True, skipped=[], expectedFailure=None, errors=[(<...>, None)]) at remote 0x7fffeac33fa0>, _testMethodDoc=None, _cleanups=[], _subtest=None, ...(truncated)) at Python/ceval.c:741
#47 _PyEval_EvalCodeWithName (_co=<optimized out>, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=<optimized out>, kwnames=0x0, kwargs=0x7fffffffb590, kwcount=0, kwstep=1, defs=0x7ffff2f192c8, defcount=1, kwdefs=0x0, closure=0x0, 
    name='run', qualname='TestCase.run') at Python/ceval.c:4298
This crashes when derefencing a == ((vtkXMLUnstructuredGridWriter)(this))->Cellpoints) in https://gitlab.kitware.com/vtk/vtk/-/bl ... .cxx#L2060

Code: Select all

2060      this->WriteWordTypeAttribute("type", a->GetDataType());

bt 5
#0  vtkXMLWriter::WriteArrayHeader (this=0x555555a053b0, a=0x0, indent=..., alternateName=0x0, writeNumTuples=0, timestep=0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLWriter.cxx:2060
#1  0x00007ffff1e73b44 in vtkXMLWriter::WriteArrayInline (this=this@entry=0x555555a053b0, a=0x0, indent=..., alternateName=alternateName@entry=0x0, writeNumTuples=writeNumTuples@entry=0) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLWriter.cxx:2163
#2  0x00007ffff1e5c6e9 in vtkXMLUnstructuredDataWriter::WriteCellsInlineWorker (this=0x555555a053b0, name=0x7ffff1e7e348 "Cells", types=0x0, indent=...) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/Core/vtkSmartPointer.h:195
#3  0x00007ffff1e6647c in vtkXMLUnstructuredGridWriter::WriteInlinePiece (this=this@entry=0x555555a053b0, indent=...) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/Common/Core/vtkSmartPointer.h:195
#4  0x00007ffff1e5ba9e in vtkXMLUnstructuredDataWriter::WriteInlineMode (this=0x555555a053b0, indent=...) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLUnstructuredDataWriter.cxx:473
(Unfortunately, the smart pointer dereferences in the call have clobbered the actual location, which is:

Code: Select all

#0  vtkXMLUnstructuredDataWriter::WriteCellsInlineWorker (this=0x555555a053b0, name=0x7ffff1e7e348 "Cells", types=0x0, indent=...) at /usr/src/debug/vtk-9.1.0-177.9.x86_64/IO/XML/vtkXMLUnstructuredDataWriter.cxx:680

680       this->WriteArrayInline(this->CellPoints, indent.GetNextIndent());

p this->CellPoints
$19 = {<vtkSmartPointerBase> = {Object = 0x0}, <No data fields>}
Last edited by StefanBruens on Mon Apr 04, 2022 3:37 pm, edited 1 time in total.
StefanBruens
Posts: 24
Joined: Sun Nov 29, 2020 5:30 am

Re: Crashes in FEM test suite

Post by StefanBruens »

Temporary files
Attachments
all_objects.FCStd.21d2a6ca-9ab2-494e-8d64-ca78f004225b.FCStd
(16.98 KiB) Downloaded 26 times
fileoiObmy.xml
Partial output from vtkXML
(754 Bytes) Downloaded 26 times
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Crashes in FEM test suite

Post by wmayer »

I can confirm that there must be a regression. I had an older build of git commit 7734017cd6ea705 that perfectly worked with vtk9.0.0. With current master it crashes now.

My regular build uses vtk7 and doesn't suffer from the regression. Recently I made a fix on the smesh version to work properly with vtk9.x: git commit 7734017cd

But this isn't the culprit because when undoing the changes the crash still happens. So, I guess it must be one of the many changes done on the FEM module.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Crashes in FEM test suite

Post by wmayer »

Reverting all recent changes made to FEM showed that this commit is to blame: git commit 708a300b9341838
uwestoehr wrote: ping
Because of the introduction of the new mode Custom and setting it as default the property PropertyPostDataObject will never be changed and the internal vtkDataObject might be in an invalid state which then leads to the crash.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: Crashes in FEM test suite

Post by uwestoehr »

wmayer wrote: Mon Apr 04, 2022 7:08 pm Because of the introduction of the new mode Custom and setting it as default the property PropertyPostDataObject will never be changed and the internal vtkDataObject might be in an invalid state which then leads to the crash.
The idea of the Custom mode is to change nothing but to respect the user's will. PropertyPostDataObject is therefore object the user chose for the filter. So it seems I must adapt a test to explicitly set the PropertyPostDataObject.

Since I don't get a crash, not even a warning when running the FEM tests. Can you therefore please tell me for what particular test you get the crash?
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Crashes in FEM test suite

Post by wmayer »

uwestoehr wrote: Tue Apr 05, 2022 1:03 am Since I don't get a crash, not even a warning when running the FEM tests. Can you therefore please tell me for what particular test you get the crash?

Code: Select all

./FreeCADCmd -t "femtest.app.test_object.TestObjectCreate"
But as said it depends on the vtk version. With vtk7 everything is fine while vtk9 crashes. The difficulty is to figure out when the vtkDataSet object is in a state where it cannot be exported.
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: Crashes in FEM test suite

Post by uwestoehr »

wmayer wrote: Tue Apr 05, 2022 5:31 am ./FreeCADCmd -t "femtest.app.test_object.TestObjectCreate"

But as said it depends on the vtk version. With vtk7 everything is fine while vtk9 crashes. The difficulty is to figure out when the vtkDataSet object is in a state where it cannot be exported.
I have VTK 8.2 and don't get any problems.

Since the failing test in class TestObjectCreate in test_object.py, I will have to look at this.
I think the fix is to either explicitly set either an explicit PropertyPostDataObject or to setup the pipeline not using the Custom mode but another mode. Since I don't have VTK 9, I can only experiment and make a PR that you can test if this helps.

(The custom option fixes several issues with the pipeline handling because it assures that the input of the filters is not changed automatically against the user's will. For example it is valid and also useful to have e.g. a scalar filter and a cut filter that takes the same filter as input.)
User avatar
uwestoehr
Veteran
Posts: 4961
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany
Contact:

Re: Crashes in FEM test suite

Post by uwestoehr »

uwestoehr wrote: Tue Apr 05, 2022 10:58 am I think the fix is to either explicitly set either an explicit PropertyPostDataObject or to setup the pipeline not using the Custom mode but another mode. Since I don't have VTK 9, I can only experiment and make a PR that you can test if this helps.
OK, I think the fix would be to add this line after line 685 in the class def makePostVtkResult() in ObjectsFem.py:

Code: Select all

obj.mode = 0
I cannot test anything right now, but maybe someone with VTK 9 could give this a try?
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Crashes in FEM test suite

Post by wmayer »

I have VTK 8.2 and don't get any problems.
It looks like it's a regression since vtk 9.0. They made huge changes in the API and the internal working and when looking at their bug tracker there are more bugs of this kind.

Anyway after experimenting a while I tried to dump the meta information of a given vtkDataObject to std::cerr. The output of an object that can be exported looks like this:

Code: Select all

vtkUnstructuredGrid (0x169df40)
  Debug: Off
  Modified Time: 267
  Reference Count: 7
  Registered Events: (none)
  Information: 0x169c100
  Data Released: False
  Global Release Data: Off
  UpdateTime: 1001
  Field Data:
    Debug: Off
    Modified Time: 265
    Reference Count: 1
    Registered Events: (none)
    Number Of Arrays: 0
    Number Of Components: 0
    Number Of Tuples: 0
  Number Of Points: 0
  Number Of Cells: 0
  Cell Data:
    Debug: Off
    Modified Time: 262
    Reference Count: 1
    Registered Events: 
      Registered Observers:
        vtkObserver (0x169dd60)
          Event: 33
          EventName: ModifiedEvent
          Command: 0x169c2b0
          Priority: 0
          Tag: 1
    Number Of Arrays: 0
    Number Of Components: 0
    Number Of Tuples: 0
    Copy Tuple Flags: ( 1 1 1 1 1 0 1 1 )
    Interpolate Flags: ( 1 1 1 1 1 0 0 1 )
    Pass Through Flags: ( 1 1 1 1 1 1 1 1 )
    Scalars: (none)
    Vectors: (none)
    Normals: (none)
    TCoords: (none)
    Tensors: (none)
    GlobalIds: (none)
    PedigreeIds: (none)
    EdgeFlag: (none)
  Point Data:
    Debug: Off
    Modified Time: 264
    Reference Count: 1
    Registered Events: 
      Registered Observers:
        vtkObserver (0x169da00)
          Event: 33
          EventName: ModifiedEvent
          Command: 0x169c2b0
          Priority: 0
          Tag: 1
    Number Of Arrays: 0
    Number Of Components: 0
    Number Of Tuples: 0
    Copy Tuple Flags: ( 1 1 1 1 1 0 1 1 )
    Interpolate Flags: ( 1 1 1 1 1 0 0 1 )
    Pass Through Flags: ( 1 1 1 1 1 1 1 1 )
    Scalars: (none)
    Vectors: (none)
    Normals: (none)
    TCoords: (none)
    Tensors: (none)
    GlobalIds: (none)
    PedigreeIds: (none)
    EdgeFlag: (none)
  Bounds: 
    Xmin,Xmax: (1e+299, -1e+299)
    Ymin,Ymax: (1e+299, -1e+299)
    Zmin,Zmax: (1e+299, -1e+299)
  Compute Time: 1150
  Number Of Points: 0
  Point Coordinates: 0x169de30
  Locator: 0
  Number Of Pieces: 1
  Piece: 0
  Ghost Level: 0
and the output of an object that causes a crash looks like this:

Code: Select all

vtkUnstructuredGrid (0x19a8160)
  Debug: Off
  Modified Time: 847
  Reference Count: 3
  Registered Events: (none)
  Information: 0x16a88c0
  Data Released: False
  Global Release Data: Off
  UpdateTime: 0
  Field Data:
    Debug: Off
    Modified Time: 845
    Reference Count: 1
    Registered Events: (none)
    Number Of Arrays: 0
    Number Of Components: 0
    Number Of Tuples: 0
  Number Of Points: 0
  Number Of Cells: 0
  Cell Data:
    Debug: Off
    Modified Time: 842
    Reference Count: 1
    Registered Events: 
      Registered Observers:
        vtkObserver (0x19d12c0)
          Event: 33
          EventName: ModifiedEvent
          Command: 0x19c9ef0
          Priority: 0
          Tag: 1
    Number Of Arrays: 0
    Number Of Components: 0
    Number Of Tuples: 0
    Copy Tuple Flags: ( 1 1 1 1 1 0 1 1 )
    Interpolate Flags: ( 1 1 1 1 1 0 0 1 )
    Pass Through Flags: ( 1 1 1 1 1 1 1 1 )
    Scalars: (none)
    Vectors: (none)
    Normals: (none)
    TCoords: (none)
    Tensors: (none)
    GlobalIds: (none)
    PedigreeIds: (none)
    EdgeFlag: (none)
  Point Data:
    Debug: Off
    Modified Time: 844
    Reference Count: 1
    Registered Events: 
      Registered Observers:
        vtkObserver (0x19cfba0)
          Event: 33
          EventName: ModifiedEvent
          Command: 0x19c9ef0
          Priority: 0
          Tag: 1
    Number Of Arrays: 0
    Number Of Components: 0
    Number Of Tuples: 0
    Copy Tuple Flags: ( 1 1 1 1 1 0 1 1 )
    Interpolate Flags: ( 1 1 1 1 1 0 0 1 )
    Pass Through Flags: ( 1 1 1 1 1 1 1 1 )
    Scalars: (none)
    Vectors: (none)
    Normals: (none)
    TCoords: (none)
    Tensors: (none)
    GlobalIds: (none)
    PedigreeIds: (none)
    EdgeFlag: (none)
  Bounds: 
    Xmin,Xmax: (1e+299, -1e+299)
    Ymin,Ymax: (1e+299, -1e+299)
    Zmin,Zmax: (1e+299, -1e+299)
  Compute Time: 1432
  Number Of Points: 0
  Point Coordinates: 0x19c9660
  Locator: 0
  Number Of Pieces: 1
  Piece: -1
  Ghost Level: 0
The only real difference is the field Piece. For a valid object it's 0 (and probably any positive value) and for an invalid object -1. Does anybody know what's the exact meaning of Piece is?

When creating the XML file then it looks like this when it worked:

Code: Select all

<?xml version="1.0"?>
<VTKFile type="UnstructuredGrid" version="0.1" byte_order="LittleEndian" header_type="UInt32" compressor="vtkZLibDataCompressor">
  <UnstructuredGrid>
    <Piece NumberOfPoints="0" NumberOfCells="0">
      <PointData>
      </PointData>
      <CellData>
      </CellData>
      <Points>
        <DataArray type="Float32" Name="Points" NumberOfComponents="3" format="binary" RangeMin="1e+299" RangeMax="-1e+299">
          AAAAAACAAAAAAAAA
          <InformationKey name="L2_NORM_RANGE" location="vtkDataArray" length="2">
            <Value index="0">
              1e+299
            </Value>
            <Value index="1">
              -1e+299
            </Value>
          </InformationKey>
        </DataArray>
      </Points>
      <Cells>
        <DataArray type="Int64" Name="connectivity" format="binary" RangeMin="1e+299" RangeMax="-1e+299">
          AAAAAACAAAAAAAAA
        </DataArray>
        <DataArray type="Int64" Name="offsets" format="binary" RangeMin="1e+299" RangeMax="-1e+299">
          AAAAAACAAAAAAAAA
        </DataArray>
        <DataArray type="UInt8" Name="types" format="binary" RangeMin="1e+299" RangeMax="-1e+299">
          AAAAAACAAAAAAAAA
        </DataArray>
      </Cells>
    </Piece>
  </UnstructuredGrid>
</VTKFile>
and this way when it crashes:

Code: Select all

<?xml version="1.0"?>
<VTKFile type="UnstructuredGrid" version="0.1" byte_order="LittleEndian" header_type="UInt32" compressor="vtkZLibDataCompressor">
  <UnstructuredGrid>
    <Piece NumberOfPoints="0" NumberOfCells="0">
      <PointData>
      </PointData>
      <CellData>
      </CellData>
      <Points>
        <DataArray type="Float32" Name="Points" NumberOfComponents="3" format="binary" RangeMin="1e+299" RangeMax="-1e+299">
          AAAAAACAAAAAAAAA
          <InformationKey name="L2_NORM_RANGE" location="vtkDataArray" length="2">
            <Value index="0">
              1e+299
            </Value>
            <Value index="1">
              -1e+299
            </Value>
          </InformationKey>
        </DataArray>
      </Points>
So, it's when trying to write the cell information where it crashes.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Crashes in FEM test suite

Post by wmayer »

So, for now this is a work around: git commit c3ec0b7c49
Post Reply