[Paraview] [BUG] segfault playing a simulation
Cory Quammen
cory.quammen at kitware.com
Tue Aug 11 10:32:25 EDT 2015
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/paraview/attachments/20150811/9e5989c9/attachment.html>
More information about the ParaView
mailing list