[Paraview] [BUG] segfault playing a simulation
Sergi Mateo Bellido
sergi.mateo.bellido at gmail.com
Tue Aug 11 01:35:34 EDT 2015
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
> <mailto: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
> <mailto: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
>>>>> <mailto: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
>>>>>> <mailto: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
>>>>>>> <mailto: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
>>>>>>>> <mailto: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
>>>>>>>> <mailto:sergi.mateo.bellido at gmail.com>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Powered by www.kitware.com
>>>>>>>> <http://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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150811/cd2012dd/attachment.html>
More information about the ParaView
mailing list