[Paraview] [BUG] segfault playing a simulation

Cory Quammen cory.quammen at kitware.com
Tue Aug 11 14:32:01 EDT 2015 

Sergi,

Okay, I think I understand what is going on. Recall that you were seeing
that the reader was trying to read an extra slice of the first piece. After
looking at another example of a multipiece XML image file, it is apparent
that you are in fact expected to provide that extra slice in your first
piece. So if you change your writer to write the extra slice, that should
solve the problem.

I'm checking to see if this is documented anywhere.

Cheers,
Cory

On Tue, Aug 11, 2015 at 10:32 AM, Cory Quammen <cory.quammen at kitware.com>
wrote:

> I do sometimes get a crash. I'm still looking into it.
>
> Cory
>
> On Tue, Aug 11, 2015 at 1:35 AM, Sergi Mateo Bellido <
> sergi.mateo.bellido at gmail.com> wrote:
>
>> Hi Cory,
>>
>> Apart from that issues, Could you reproduce the segfault? I was running
>> the client directly, I wasn't using the server.
>>
>> Thanks!
>> Sergi
>>
>>
>> On 08/10/2015 05:12 PM, Cory Quammen wrote:
>>
>> Sergi,
>>
>> Quick update:
>>
>> I'm having even stranger behavior than a crash. When I load the ascii
>> files you sent in mpi_test.tar.gz with ParaView running with the built-in
>> server, I can see the different values of "var" for the first and second
>> blocks (0 and 1, respectively). The same is true when I run a separate
>> pvserver and connect to it from the client.
>>
>> However, when I connect to a server running with
>>
>> mpirun -np2 pvserver
>>
>> "var" has only the value 0.
>>
>> This same behavior occurs for the zipped_binary and raw_binary files as
>> well.
>>
>> I'll look into it some more.
>>
>> Thanks,
>> Cory
>>
>> On Fri, Aug 7, 2015 at 2:32 PM, Cory Quammen <cory.quammen at kitware.com>
>> wrote:
>>
>>> Sergi,
>>>
>>> Thanks for investigating and posting the information. I will take a look.
>>>
>>> - Cory
>>>
>>> On Sun, Aug 2, 2015 at 12:41 PM, Sergi Mateo Bellido <
>>> sergi.mateo.bellido at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> After a few hours debugging ParaView's code I think that I finally
>>>> found the bug! :)
>>>>
>>>> The problem is that the meaning of the piece extent changes depending
>>>> on if the piece has the whole dimensions or only a portion of them. For
>>>> example, imagine that we have the following *.pvti file:
>>>>
>>>> <VTKFile type="PImageData"  ... compressor="vtkZLibDataCompressor">
>>>>   <PImageData WholeExtent="0 200 0 200 0 200" ...>
>>>>     <PPointData>
>>>>       <PDataArray type="Float32" ..."/>
>>>>     </PPointData>
>>>>     <Piece Extent="0 200 0 200 0 101" Source="raw_binary_0_0.vti"/>
>>>>     <Piece Extent="0 200 0 200 101 200" Source="raw_binary_0_1.vti"/>
>>>>   </PImageData>
>>>> </VTKFile>
>>>>
>>>> In this case, the dimensions of the pieces are:
>>>>   1st piece -> [0..200], [0..200], [0..101)
>>>>   2nd piece -> [0..200], [0..200], [101..200]
>>>>
>>>> Note that the last dimension range of the 1st piece doesn't include the
>>>> 101 value which is included in the 2nd piece.
>>>>
>>>> The issue here is that the code is not taking into account this when
>>>> it's computing the dimensions of the current piece. In file
>>>> VTK/IO/XML/vtkXMLPStructuredDataReader.cxx:155 we have the next call to
>>>> 'ComputePointDimensions' function:
>>>>
>>>>  this->ComputePointDimensions(this->SubExtent,
>>>> this->SubPointDimensions);
>>>>
>>>> I printed the values of 'this->SubExtent' and they were the same values
>>>> specified in the Piece Extent field:
>>>>
>>>> (gdb) p SubExtent
>>>> $1 = {0, 200, 0, 200, 0, 101}
>>>>
>>>> For these values, the 'ComputePointDimensions' function, which is
>>>> defined in VTK/IO/XML/vtkXMLReader.cxx:916, computed the next dimensions:
>>>>
>>>> (gdb) p this->SubPointDimensions
>>>> $2 = {201, 201, 102}
>>>>
>>>> How these values are computed is very simple: upper_bound - lower_bound
>>>> + 1. Note that the value of the third dimension is wrong: it should be 101
>>>> instead of 102.
>>>>
>>>> Finally, the segfault is produced in the 'CopySubExtent' function,
>>>> which is defined in VTK/IO/XML/vtkXMLPStructuredDataReader.cxx:342, because
>>>> SubPointDimensions information is used to copy the regions and we are doing
>>>> an extra copy (loop defined in 371 line).
>>>>
>>>> Could you confirm me this bug?
>>>>
>>>> Best regards,
>>>>
>>>> Sergi Mateo
>>>>
>>>> PS1: Source references are related to the last version of ParaView's
>>>> source published in your webpage:
>>>> http://www.paraview.org/paraview-downloads/download.php?submit=Download&version=v4.3&type=source&os=all&downloadFile=ParaView-v4.3.1-source.tar.gz
>>>>
>>>> PS2: You can reproduce this bug using one of the examples that I sent
>>>> you in my previous emails.
>>>>
>>>> On 07/24/2015 11:24 AM, Sergi Mateo Bellido wrote:
>>>>
>>>> Hi Cory,
>>>>
>>>> I have been doing some experiments with the encoding formats but I've
>>>> not progressed much.
>>>>
>>>> The elements of my mesh are floats and the mesh dimensions are
>>>> 201x201x201 (X,Y,Z). I executed all the experiments with 2 MPI processes
>>>> and the data domain was manually partionated by the Z axis, i.e. each
>>>> process computes half of the cube.
>>>>
>>>> The program basically writes, at each position of the mesh, the
>>>> identifier of the MPI process that computed that position (mpi rank). In
>>>> our case, this means that half of the cube has a '0' whereas the other
>>>> portion has a '1'.
>>>>
>>>> Attached to this email you will  a tarball with 3 outputs, one for each
>>>> different encoding (ASCII, zipped binary, raw binary). The size of the mesh
>>>> is 201x201x201 and the only difference among the executions is the encoding
>>>> format.
>>>>
>>>> I hope you could give me some light.
>>>>
>>>> Thanks!
>>>>
>>>> Sergi
>>>>
>>>> On 07/17/2015 04:21 PM, Sergi Mateo Bellido wrote:
>>>>
>>>> Hi again,
>>>>
>>>> I've just tried storing the data as a binary and It  crashes. In this
>>>> case we are not using the offset field either.
>>>>
>>>> May the problem be related to the data compression?
>>>>
>>>> Best,
>>>> Sergi
>>>>
>>>> On 07/17/2015 03:38 PM, Sergi Mateo Bellido wrote:
>>>>
>>>> Hi Cory,
>>>>
>>>> Your intuition was right: the problem is related in some way with the
>>>> offset. I've changed the DataMote to ASCII and everything worked :)  Note
>>>> that in this mode the offset field is not used, instead of that VTK
>>>> generates a DataArray.
>>>>
>>>> I would like to know how the offset is computed since I can't find any
>>>> relation between the  offset value and my data.
>>>>
>>>> Thanks!
>>>>
>>>> Sergi
>>>>
>>>> On 07/13/2015 03:51 AM, Cory Quammen wrote:
>>>>
>>>> Sergi,
>>>>
>>>> Your VTI file extents should only describe the region of the whole
>>>> image they occupy, so you are on the right track. In situations like these
>>>> where it isn't obvious what is wrong, I tend to start from the beginning
>>>> with a very small example and build up from there. For example, you could
>>>> start with a small image - say 2 x 4 pixels (2D) split into two pieces.
>>>> Start with one data array for this example and make sure it works - use
>>>> ASCII encoding so that you know for sure what is in the XML file and then
>>>> switch to raw binary, then zipped binary. Then add a second data array.
>>>> When you are confident that works, change the example to four pieces, then
>>>> make the image 3D and so on.
>>>>
>>>> It can take a while to do this, but you'll come out really
>>>> understanding the file format and will probably figure out what you had
>>>> wrong in the first place.
>>>>
>>>> Thanks,
>>>> Cory
>>>>
>>>> On Sat, Jul 11, 2015 at 5:32 AM, Sergi Mateo Bellido <
>>>> sergi.mateo.bellido at gmail.com> wrote:
>>>>
>>>>> Hi Cory,
>>>>>
>>>>> Thanks for your time. I have been playing a bit with the files too and
>>>>> I realized that replacing the whole_extent of each *.vti  by the whole
>>>>> dataset everything works.
>>>>>
>>>>> I would like to generate something like this:
>>>>> http://vtk.1045678.n5.nabble.com/Example-vti-file-td3381382.html . In
>>>>> this example, each imagedata has whole_extent=whole size but its pieces
>>>>> only contain a portion of the whole dataset. Does this configuration make
>>>>> sense?
>>>>>
>>>>> I have been trying to generate something like that but I failed. My
>>>>> code looks like this one:
>>>>> http://www.vtk.org/Wiki/VTK/Examples/Cxx/IO/WriteVTI but using
>>>>> VtkFloatArray as buffers and attaching them to the VtkImageData. I tried
>>>>> defining the set of the VtkImageData as the whole dataset and defining the
>>>>> VtkFloatArrays of the size of each portion but it didn't work :(
>>>>>
>>>>> Any clue?
>>>>>
>>>>> Thanks!
>>>>> Sergi
>>>>>
>>>>>
>>>>> On 07/09/2015 05:00 PM, Cory Quamen wrote:
>>>>>
>>>>> Hi Sergi,
>>>>>
>>>>> I played with your data set a little but haven't found what is wrong.
>>>>> I am suspicious of two things in the data file, the extent and the offset
>>>>> in the second data array (it looks too small).
>>>>>
>>>>> What are the dimensions of your grid? Note that the whole extent upper
>>>>> values need to be the dimension - 1, e.g., for a 300x300x300 grid, the
>>>>> whole extent should be 0 299 0 299 0 299.
>>>>>
>>>>> Thanks,
>>>>> Cory
>>>>>
>>>>> On Wed, Jul 1, 2015 at 12:27 PM, Sergi Mateo Bellido <
>>>>> sergi.mateo.bellido at gmail.com> wrote:
>>>>>
>>>>>> Hi Cory,
>>>>>>
>>>>>> Thanks for your time. These data files have been produced by a
>>>>>> software that I'm developing with some colleagues.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Sergi
>>>>>>
>>>>>>
>>>>>> On 07/01/2015 03:59 PM, Cory Quammen wrote:
>>>>>>
>>>>>> Sergi,
>>>>>>
>>>>>> I can confirm the crash you are seeing in the same location in the
>>>>>> code. I'm looking for the cause.
>>>>>>
>>>>>> What software produced these data files?
>>>>>>
>>>>>> Thanks,
>>>>>> Cory
>>>>>>
>>>>>> On Wed, Jul 1, 2015 at 1:59 AM, Sergi Mateo Bellido <
>>>>>> sergi.mateo.bellido at gmail.com> wrote:
>>>>>>
>>>>>>> Hi Cory,
>>>>>>>
>>>>>>> Thanks for your answer. I reproduced the segfault in two different
>>>>>>> ways, but it's always after loading a data set:
>>>>>>> - After loading a data set, I tried to play the simulation ->segfault
>>>>>>> - After loading a data set, I tried to filter some fields from the
>>>>>>> model (Pointer array status). As soon as I clicked the 'apply' button,
>>>>>>> paraview crashed with a segfault.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sergi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 06/30/2015 06:21 AM, Cory Quammen wrote:
>>>>>>>
>>>>>>> Hi Sergi,
>>>>>>>
>>>>>>> Could you clarify when you are seeing this crash? Is it right when
>>>>>>> starting ParaView or when first loading a data set?
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Cory
>>>>>>>
>>>>>>> On Tue, Jun 23, 2015 at 8:55 AM, Sergi Mateo Bellido <
>>>>>>> sergi.mateo.bellido at gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm trying to reproduce a simulation with ParaView 4.3.1 and it
>>>>>>>> always crashes when I start it. You can find the backtrace below:
>>>>>>>>
>>>>>>>> =========================================================
>>>>>>>> Process id 6681 Caught SIGSEGV at 0x925b124 address not mapped to
>>>>>>>> object
>>>>>>>> Program Stack:
>>>>>>>> WARNING: The stack trace will not use advanced capabilities because
>>>>>>>> this is a release build.
>>>>>>>> 0x7f54ce081d40 : ??? [(???) ???:-1]
>>>>>>>> 0x7f54ce19caf6 : ??? [(???) ???:-1]
>>>>>>>> 0x7f54cb123736 : vtkXMLPStructuredDataReader::CopySubExtent(int*,
>>>>>>>> int*, long long*, int*, int*, long long*, int*, int*, vtkDataArray*,
>>>>>>>> vtkDataArray*) [(libvtkIOXML-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cb12389f :
>>>>>>>> vtkXMLPStructuredDataReader::CopyArrayForPoints(vtkDataArray*,
>>>>>>>> vtkDataArray*) [(libvtkIOXML-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cb11cc1f : vtkXMLPDataReader::ReadPieceData()
>>>>>>>> [(libvtkIOXML-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cb11ca14 : vtkXMLPDataReader::ReadPieceData(int)
>>>>>>>> [(libvtkIOXML-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cb124d7a : vtkXMLPStructuredDataReader::ReadXMLData()
>>>>>>>> [(libvtkIOXML-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cb1280eb : vtkXMLReader::RequestData(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*) [(libvtkIOXML-pv4.3.so.1)
>>>>>>>> ???:-1]
>>>>>>>> 0x7f54cb1273b6 : vtkXMLReader::ProcessRequest(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*) [(libvtkIOXML-pv4.3.so.1)
>>>>>>>> ???:-1]
>>>>>>>> 0x7f54cd6200f9 : vtkFileSeriesReader::RequestData(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*)
>>>>>>>> [(libvtkPVVTKExtensionsDefault-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cd61f07f :
>>>>>>>> vtkFileSeriesReader::ProcessRequest(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*)
>>>>>>>> [(libvtkPVVTKExtensionsDefault-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d2706204 : vtkExecutive::CallAlgorithm(vtkInformation*, int,
>>>>>>>> vtkInformationVector**, vtkInformationVector*)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d27016cc :
>>>>>>>> vtkDemandDrivenPipeline::ExecuteData(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d2700201 :
>>>>>>>> vtkCompositeDataPipeline::ExecuteData(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d2704067 :
>>>>>>>> vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d271d959 :
>>>>>>>> vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d26fe387 :
>>>>>>>> vtkCompositeDataPipeline::ForwardUpstream(vtkInformation*)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d2704010 :
>>>>>>>> vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d271d959 :
>>>>>>>> vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d26fe387 :
>>>>>>>> vtkCompositeDataPipeline::ForwardUpstream(vtkInformation*)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d2704010 :
>>>>>>>> vtkDemandDrivenPipeline::ProcessRequest(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d271d959 :
>>>>>>>> vtkStreamingDemandDrivenPipeline::ProcessRequest(vtkInformation*,
>>>>>>>> vtkInformationVector**, vtkInformationVector*)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d27035ae : vtkDemandDrivenPipeline::UpdateData(int)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d271e87f : vtkStreamingDemandDrivenPipeline::Update(int)
>>>>>>>> [(libvtkCommonExecutionModel-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cd98fa7f :
>>>>>>>> vtkPVDataRepresentation::ProcessViewRequest(vtkInformationRequestKey*,
>>>>>>>> vtkInformation*, vtkInformation*)
>>>>>>>> [(libvtkPVClientServerCoreRendering-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cd973d79 :
>>>>>>>> vtkGeometryRepresentation::ProcessViewRequest(vtkInformationRequestKey*,
>>>>>>>> vtkInformation*, vtkInformation*)
>>>>>>>> [(libvtkPVClientServerCoreRendering-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cd975d71 :
>>>>>>>> vtkGeometryRepresentationWithFaces::ProcessViewRequest(vtkInformationRequestKey*,
>>>>>>>> vtkInformation*, vtkInformation*)
>>>>>>>> [(libvtkPVClientServerCoreRendering-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cd9bd388 :
>>>>>>>> vtkPVView::CallProcessViewRequest(vtkInformationRequestKey*,
>>>>>>>> vtkInformation*, vtkInformationVector*)
>>>>>>>> [(libvtkPVClientServerCoreRendering-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cd9bd552 : vtkPVView::Update()
>>>>>>>> [(libvtkPVClientServerCoreRendering-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cd9acb78 : vtkPVRenderView::Update()
>>>>>>>> [(libvtkPVClientServerCoreRendering-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d780ac30 :
>>>>>>>> vtkPVRenderViewCommand(vtkClientServerInterpreter*, vtkObjectBase*, char
>>>>>>>> const*, vtkClientServerStream const&, vtkClientServerStream&, void*)
>>>>>>>> [(libvtkPVServerManagerApplication-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d4e135e0 :
>>>>>>>> vtkClientServerInterpreter::CallCommandFunction(char const*,
>>>>>>>> vtkObjectBase*, char const*, vtkClientServerStream const&,
>>>>>>>> vtkClientServerStream&) [(libvtkClientServer-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d4e18393 :
>>>>>>>> vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream
>>>>>>>> const&, int) [(libvtkClientServer-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d4e16832 :
>>>>>>>> vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&,
>>>>>>>> int) [(libvtkClientServer-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d4e16ced :
>>>>>>>> vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&)
>>>>>>>> [(libvtkClientServer-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d5b26cec :
>>>>>>>> vtkPVSessionCore::ExecuteStreamInternal(vtkClientServerStream const&, bool)
>>>>>>>> [(libvtkPVServerImplementationCore-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d5b26958 : vtkPVSessionCore::ExecuteStream(unsigned int,
>>>>>>>> vtkClientServerStream const&, bool)
>>>>>>>> [(libvtkPVServerImplementationCore-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d5b25203 : vtkPVSessionBase::ExecuteStream(unsigned int,
>>>>>>>> vtkClientServerStream const&, bool)
>>>>>>>> [(libvtkPVServerImplementationCore-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cdcae44f : vtkSMViewProxy::Update()
>>>>>>>> [(libvtkPVServerManagerRendering-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cdf2f6f7 : vtkSMAnimationScene::TickInternal(double, double,
>>>>>>>> double) [(libvtkPVAnimation-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cf415cab : vtkAnimationCue::Tick(double, double, double)
>>>>>>>> [(libvtkCommonCore-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cdf23268 : vtkAnimationPlayer::Play()
>>>>>>>> [(libvtkPVAnimation-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d7851619 :
>>>>>>>> vtkSMAnimationSceneCommand(vtkClientServerInterpreter*, vtkObjectBase*,
>>>>>>>> char const*, vtkClientServerStream const&, vtkClientServerStream&, void*)
>>>>>>>> [(libvtkPVServerManagerApplication-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d4e135e0 :
>>>>>>>> vtkClientServerInterpreter::CallCommandFunction(char const*,
>>>>>>>> vtkObjectBase*, char const*, vtkClientServerStream const&,
>>>>>>>> vtkClientServerStream&) [(libvtkClientServer-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d4e18393 :
>>>>>>>> vtkClientServerInterpreter::ProcessCommandInvoke(vtkClientServerStream
>>>>>>>> const&, int) [(libvtkClientServer-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d4e16832 :
>>>>>>>> vtkClientServerInterpreter::ProcessOneMessage(vtkClientServerStream const&,
>>>>>>>> int) [(libvtkClientServer-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d4e16ced :
>>>>>>>> vtkClientServerInterpreter::ProcessStream(vtkClientServerStream const&)
>>>>>>>> [(libvtkClientServer-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d5b436d4 :
>>>>>>>> vtkSIProperty::ProcessMessage(vtkClientServerStream&)
>>>>>>>> [(libvtkPVServerImplementationCore-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d5b4377e : vtkSIProperty::Push(paraview_protobuf::Message*,
>>>>>>>> int) [(libvtkPVServerImplementationCore-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d5b4459e : vtkSIProxy::Push(paraview_protobuf::Message*)
>>>>>>>> [(libvtkPVServerImplementationCore-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d5b2884a :
>>>>>>>> vtkPVSessionCore::PushStateInternal(paraview_protobuf::Message*)
>>>>>>>> [(libvtkPVServerImplementationCore-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d5b27484 :
>>>>>>>> vtkPVSessionCore::PushState(paraview_protobuf::Message*)
>>>>>>>> [(libvtkPVServerImplementationCore-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d5b2514d :
>>>>>>>> vtkPVSessionBase::PushState(paraview_protobuf::Message*)
>>>>>>>> [(libvtkPVServerImplementationCore-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d5d859b7 : vtkSMProxy::UpdateProperty(char const*, int)
>>>>>>>> [(libvtkPVServerManagerCore-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54d6d8aa07 : pqVCRController::onPlay()
>>>>>>>> [(libvtkpqComponents-pv4.3.so.1) ???:-1]
>>>>>>>> 0x7f54cfa98258 : QMetaObject::activate(QObject*, QMetaObject
>>>>>>>> const*, int, void**) [(libQtCore.so.4) ???:-1]
>>>>>>>> 0x7f54d01102f2 : QAction::triggered(bool) [(libQtGui.so.4) ???:-1]
>>>>>>>> 0x7f54d0111710 : QAction::activate(QAction::ActionEvent)
>>>>>>>> [(libQtGui.so.4) ???:-1]
>>>>>>>> 0x7f54d04fd514 : ??? [(???) ???:-1]
>>>>>>>> 0x7f54d04fd7ab : QAbstractButton::mouseReleaseEvent(QMouseEvent*)
>>>>>>>> [(libQtGui.so.4) ???:-1]
>>>>>>>> 0x7f54d05d15ea : QToolButton::mouseReleaseEvent(QMouseEvent*)
>>>>>>>> [(libQtGui.so.4) ???:-1]
>>>>>>>> 0x7f54d0175ac1 : QWidget::event(QEvent*) [(libQtGui.so.4) ???:-1]
>>>>>>>> 0x7f54d04fca3f : QAbstractButton::event(QEvent*) [(libQtGui.so.4)
>>>>>>>> ???:-1]
>>>>>>>> 0x7f54d05d422d : QToolButton::event(QEvent*) [(libQtGui.so.4)
>>>>>>>> ???:-1]
>>>>>>>> 0x7f54d011759e : QApplicationPrivate::notify_helper(QObject*,
>>>>>>>> QEvent*) [(libQtGui.so.4) ???:-1]
>>>>>>>> 0x7f54d011e533 : QApplication::notify(QObject*, QEvent*)
>>>>>>>> [(libQtGui.so.4) ???:-1]
>>>>>>>> 0x7f54cfa802f3 : QCoreApplication::notifyInternal(QObject*,
>>>>>>>> QEvent*) [(libQtCore.so.4) ???:-1]
>>>>>>>> 0x7f54d011a656 : QApplicationPrivate::sendMouseEvent(QWidget*,
>>>>>>>> QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer<QWidget>&, bool)
>>>>>>>> [(libQtGui.so.4) ???:-1]
>>>>>>>> 0x7f54d019ca94 : ??? [(???) ???:-1]
>>>>>>>> 0x7f54d019b877 : QApplication::x11ProcessEvent(_XEvent*)
>>>>>>>> [(libQtGui.so.4) ???:-1]
>>>>>>>> 0x7f54d01c4805 : ??? [(???) ???:-1]
>>>>>>>> 0x7f54cfa7f375 :
>>>>>>>> QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
>>>>>>>> [(libQtCore.so.4) ???:-1]
>>>>>>>> 0x7f54cfa7f748 :
>>>>>>>> QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) [(libQtCore.so.4)
>>>>>>>> ???:-1]
>>>>>>>> 0x7f54cfa8414b : QCoreApplication::exec() [(libQtCore.so.4) ???:-1]
>>>>>>>> 0x407785 : main [(paraview) ???:-1]
>>>>>>>> 0x7f54ce06cec5 : __libc_start_main [(libc.so.6) ???:-1]
>>>>>>>> 0x4074da : QMainWindow::event(QEvent*) [(paraview) ???:-1]
>>>>>>>> =========================================================
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Sergi Mateo
>>>>>>>> sergi.mateo.bellido at gmail.com
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Powered by www.kitware.com
>>>>>>>>
>>>>>>>> Visit other Kitware open-source projects at
>>>>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>>>>
>>>>>>>> Please keep messages on-topic and check the ParaView Wiki at:
>>>>>>>> http://paraview.org/Wiki/ParaView
>>>>>>>>
>>>>>>>> Search the list archives at: http://markmail.org/search/?q=ParaView
>>>>>>>>
>>>>>>>> Follow this link to subscribe/unsubscribe:
>>>>>>>> http://public.kitware.com/mailman/listinfo/paraview
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cory Quammen
>>>>>>> R&D Engineer
>>>>>>> Kitware, Inc.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cory Quammen
>>>>>> R&D Engineer
>>>>>> Kitware, Inc.
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Cory Quammen
>>>>> R&D Engineer
>>>>> Kitware, Inc.
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Cory Quammen
>>>> R&D Engineer
>>>> Kitware, Inc.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Cory Quammen
>>> R&D Engineer
>>> Kitware, Inc.
>>>
>>
>>
>>
>> --
>> Cory Quammen
>> R&D Engineer
>> Kitware, Inc.
>>
>>
>>
>
>
> --
> Cory Quammen
> R&D Engineer
> Kitware, Inc.
>



-- 
Cory Quammen
R&D Engineer
Kitware, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150811/e5200b51/attachment.html>

More information about the ParaView mailing list