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