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 < [email protected]> 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 <[email protected]> > 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 < >> [email protected]> 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 < >>> [email protected]> 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 < >>>> [email protected]> 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 < >>>>> [email protected]> 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 < >>>>>> [email protected]> 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 >>>>>>> [email protected] >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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.
_______________________________________________ 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
