f3d-app
F3D segfault with a temporal .vtu file
Describe the bug F3D can open most .vtu files, but vtu file suports temporal data. Its a niche feature that is not used a lot.
To Reproduce Steps to reproduce the behavior:
- Download and extract times.zip
- Open the file using
f3d --no-config times_series.vtu - Press space
- Crash
(gdb) bt
#0 0x00007ffff60b91bb in vtkXMLUnstructuredDataReader::ReadCellArray (this=0x555555bb4910, numberOfCells=512, eCells=0x5555563102a0, outCells=0x0)
at /home/glow/dev/vtk/vtk1/src/IO/XML/vtkXMLUnstructuredDataReader.cxx:663
#1 0x00007ffff60e8443 in vtkXMLUnstructuredGridReader::ReadPieceData (this=0x555555bb4910) at /home/glow/dev/vtk/vtk1/src/IO/XML/vtkXMLUnstructuredGridReader.cxx:244
#2 0x00007ffff60417b3 in vtkXMLDataReader::ReadPieceData (this=0x555555bb4910, piece=0) at /home/glow/dev/vtk/vtk1/src/IO/XML/vtkXMLDataReader.cxx:347
#3 0x00007ffff60b772a in vtkXMLUnstructuredDataReader::ReadXMLData (this=0x555555bb4910) at /home/glow/dev/vtk/vtk1/src/IO/XML/vtkXMLUnstructuredDataReader.cxx:278
#4 0x00007ffff609288c in vtkXMLReader::RequestData (this=0x555555bb4910, outputVector=0x5555562ff9d0) at /home/glow/dev/vtk/vtk1/src/IO/XML/vtkXMLReader.cxx:752
#5 0x00007ffff6099509 in vtkXMLReader::ProcessRequest (this=0x555555bb4910, request=0x555556301300, inputVector=0x0, outputVector=0x5555562ff9d0)
at /home/glow/dev/vtk/vtk1/src/IO/XML/vtkXMLReader.cxx:2076
#6 0x00007ffff604bbce in vtkXMLGenericDataObjectReader::RequestData (this=0x555556295c10, request=0x555556301300, inputVector=0x0, outputVector=0x5555562ff9d0)
at /home/glow/dev/vtk/vtk1/src/IO/XML/vtkXMLGenericDataObjectReader.cxx:330
#7 0x00007ffff6099509 in vtkXMLReader::ProcessRequest (this=0x555556295c10, request=0x555556301300, inputVector=0x0, outputVector=0x5555562ff9d0)
at /home/glow/dev/vtk/vtk1/src/IO/XML/vtkXMLReader.cxx:2076
#8 0x00007ffff0a8cb2c in vtkExecutive::CallAlgorithm (this=0x5555562ff8a0, request=0x555556301300, direction=1, inInfo=0x0, outInfo=0x5555562ff9d0)
at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkExecutive.cxx:723
#9 0x00007ffff0a7e8c5 in vtkDemandDrivenPipeline::ExecuteData (this=0x5555562ff8a0, request=0x555556301300, inInfo=0x0, outInfo=0x5555562ff9d0)
at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:450
#10 0x00007ffff0a72587 in vtkCompositeDataPipeline::ExecuteData (this=0x5555562ff8a0, request=0x555556301300, inInfoVec=0x0, outInfoVec=0x5555562ff9d0)
at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkCompositeDataPipeline.cxx:151
#11 0x00007ffff0a7de1c in vtkDemandDrivenPipeline::ProcessRequest (this=0x5555562ff8a0, request=0x555556301300, inInfoVec=0x0, outInfoVec=0x5555562ff9d0)
at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:249
#12 0x00007ffff0b3b16e in vtkStreamingDemandDrivenPipeline::ProcessRequest (this=0x5555562ff8a0, request=0x555556301300, inInfoVec=0x0, outInfoVec=0x5555562ff9d0)
at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:336
#13 0x00007ffff0a7594a in vtkCompositeDataPipeline::ForwardUpstream (this=0x555556300990, request=0x555556301300)
at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkCompositeDataPipeline.cxx:721
#14 0x00007ffff0a7dd12 in vtkDemandDrivenPipeline::ProcessRequest (this=0x555556300990, request=0x555556301300, inInfoVec=0x5555563007c0, outInfoVec=0x555556300aa0)
at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:235
#15 0x00007ffff0b3b16e in vtkStreamingDemandDrivenPipeline::ProcessRequest (this=0x555556300990, request=0x555556301300, inInfoVec=0x5555563007c0, outInfoVec=0x555556300aa0)
at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:336
#16 0x00007ffff0a7e699 in vtkDemandDrivenPipeline::UpdateData (this=0x555556300990, outputPort=0) at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx:407
#17 0x00007ffff0b3b62e in vtkStreamingDemandDrivenPipeline::Update (this=0x555556300990, port=0, requests=0x5555565f2400)
at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkStreamingDemandDrivenPipeline.cxx:426
#18 0x00007ffff0a67053 in vtkAlgorithm::Update (this=0x555556294d90, port=0, requests=0x5555565f2400) at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkAlgorithm.cxx:1539
#19 0x00007ffff0a670f8 in vtkAlgorithm::Update (this=0x555556294d90, requests=0x55555668d210) at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkAlgorithm.cxx:1552
#20 0x00007ffff0a674d1 in vtkAlgorithm::UpdateTimeStep (this=0x555556294d90, time=0.033333333333333333, piece=-1, numPieces=1, ghostLevels=0, extents=0x0)
at /home/glow/dev/vtk/vtk1/src/Common/ExecutionModel/vtkAlgorithm.cxx:1599
#21 0x00007ffff7b1bd35 in vtkF3DGenericImporter::UpdateAtTimeValue (this=0x555556291c30, timeValue=0.033333333333333333)
at /home/glow/dev/f3d/f3d/src/vtkext/private/module/vtkF3DGenericImporter.cxx:264
#22 0x00007ffff7b2d9bd in vtkF3DMetaImporter::UpdateAtTimeValue (this=0x555555d392e0, timeValue=0.033333333333333333)
at /home/glow/dev/f3d/f3d/src/vtkext/private/module/vtkF3DMetaImporter.cxx:500
#23 0x00007ffff7a41a24 in f3d::detail::animationManager::LoadAtTime (this=0x555555d3ab48, timeValue=0.033333333333333333) at /home/glow/dev/f3d/f3d/src/library/src/animationManager.cxx:211
Expected behavior No crash and animation plays. ParaView is able to open and play the file.
F3D Information
Paste the content of f3d --version: master
I would like to work on this issue. I was busy for couple of weeks and didn't work on my other "feature"-issue, but I would rather proceed with it slowly and work a bit on "bugs" for some refreshment.
Some update on the issue.
First of all it is quite difficult to exactly compare paraview and f3d implementation as paraview in general much more complicated and it seems playing animation is done in a different way.
Another thing, paraview plays animation very fastly from 0 to 100 while f3d treats it as seconds so it takes 100 seconds to finish.
Issue itself in f3d is caused by using not initilized pointer. I attempted to do fix it in 2 ways:
1) first one in vtk/IO/XML/vtkXMLReader.cxx, I removed condition for setup to be done only once. This method sets not initialized pointer in normal run but only called once:
void vtkXMLReader::ReadXMLData()
{
// Initialize the output's data.
//if (!this->TimeStepWasReadOnce) commented out
//{ commented out
this->SetupOutputData();
//} commented out
}
But it makes rectangle spinning/acting weirdly and doesn't seem the right way.
2) Second "fix" is a bit better. Instead of reinitializing not inialized pointer I tried to disable clearing it which eventually lead it to be not initialized. In vtk/Common/ExecutionModel/vtkDemandDrivenPipeline.cxx I hardcoded not to clear data for vtkUnstructuredGrid if it was already done:
void vtkDemandDrivenPipeline::ExecuteDataStart(
vtkInformation* request, vtkInformationVector** inInfo, vtkInformationVector* outputs)
{
...
for (i = 0; i < outputs->GetNumberOfInformationObjects(); ++i)
{
vtkInformation* outInfo = outputs->GetInformationObject(i);
vtkDataObject* data = outInfo->Get(vtkDataObject::DATA_OBJECT());
vtkUnstructuredGrid* grid = vtkUnstructuredGrid::SafeDownCast(data);// addded
if (data && !outInfo->Get(DATA_NOT_GENERATED()))
{
// hardcode checking if object if unstructured grid and if it was cleared before
if(grid)
{
if(firstCall)
{
data->PrepareForNewData();
data->CopyInformationFromPipeline(outInfo);
firstCall = false;
}
}
else
{
data->PrepareForNewData();
data->CopyInformationFromPipeline(outInfo);
}
With it it seems working, except for animation working much slower than in paraview.
It doesn't seem like a proper fix, but probably highlight to what needs to be done. Maybe DATA_NOT_GENERATED() should return false after first run or something like this.
Anyway, will keep analysis
Which pointer is not initialized ?
vtkUnstructuredGrid.Connectivity as it is retrieved in vtkXMLUnstructuredGridReader::ReadPieceData() vtkUnstructuredGrid::SafeDownCast(this->GetCurrentOutput());
It is being cleaned normally and expected to be initialized, but call to initialization is prevented on other then the first pass through related code.
I investigated a bit more and it seems probably issues is related to this fixme:
vtkTypeBool vtkXMLReader::ProcessRequest(
vtkInformation* request, vtkInformationVector** inputVector, vtkInformationVector* outputVector)
{
this->CurrentOutputInformation = outputVector->GetInformationObject(0);
// FIXME This piece of code should be rewritten to handle at the same
// time Pieces and TimeSteps. The REQUEST_DATA_NOT_GENERATED should
// ideally be changed during execution, so that allocation still
// happen when needed but can be skipped in demand (when doing
// timesteps)
if (this->NumberOfTimeSteps &&
request->Has(vtkDemandDrivenPipeline::REQUEST_DATA_NOT_GENERATED()))
{
vtkInformation* outInfo = outputVector->GetInformationObject(0);
outInfo->Set(vtkDemandDrivenPipeline::DATA_NOT_GENERATED(), 1);
this->CurrentOutputInformation = nullptr;
return 1;
}
....
}
On crashing run for related request code doesn't go inside this if, but if outInfo->Set(vtkDemandDrivenPipeline::DATA_NOT_GENERATED(), 1) is executed it prevents "reset" which causes eventually having not initialized pointer.
But it is all very abstract to me as I didn't fully grasp all logic with "demand driven pipeline" and "unstructured grid".
So my understanding is that you may not have time to look deeper into this @exbluesbreaker , should I unassign it ? :)
So my understanding is that you may not have time to look deeper into this @exbluesbreaker , should I unassign it ? :)
I think I cannot work on it in near time definitely, so better to unassign. In general, it anyway requires some deeper understand of processing here. As I found potential "workaround" - having outInfo->Set(vtkDemandDrivenPipeline::DATA_NOT_GENERATED(), 1); to be set in this function, but I cannot say it is a fix.