Looks like David Gobbi's change did the trick. I'll merge that into release so it will be part of the next releases of ParaView/VTK.
On Fri, Apr 15, 2011 at 2:56 PM, Burlen Loring <[email protected]> wrote: > That would be great! Thanks Daves. > > > On 04/15/2011 11:46 AM, David Partyka wrote: > > Hey Burlen, David Gobbi just made some fixes to this and checked it into > VTK moments ago. > > > http://vtk.org/gitweb?p=VTK.git;a=commitdiff;h=d2a1fb9c5dd99830ad3cdfb753dcdd0e77268799 > > http://www.cdash.org/CDash/viewUpdate.php?buildid=976658 > > If the dashboard turns out well you should be off the hook ;-) > > On Fri, Apr 15, 2011 at 2:42 PM, Burlen Loring <[email protected]> wrote: > >> Hmm, I had tested it on XP with PV 3.8.1 and didn't have any problems. >> sorry about that, I'll have to try again. >> >> Burlen >> >> >> On 04/14/2011 07:54 PM, David Partyka wrote: >> >> Hi Burlen, I had to revert your patch as it doesn't compile on Windows.. >> >> You will have to make sure it compiles there as well and resubmit your >> patch. If you need any help please let me know. Thanks. >> >> On Thu, Apr 14, 2011 at 3:51 PM, David Partyka <[email protected] >> > wrote: >> >>> Thanks Burlen, This is applied for 3.10.2. >>> >>> >>> On Thu, Apr 14, 2011 at 2:11 PM, Burlen Loring <[email protected]> wrote: >>> >>>> Thanks Dave, >>>> >>>> Filed the bug report http://www.paraview.org/Bug/view.php?id=12087 >>>> >>>> I updated the patch for 3.10.0 as well (attached here and on the bug >>>> report). >>>> >>>> Burlen >>>> >>>> >>>> On 04/13/2011 11:24 AM, David Partyka wrote: >>>> >>>> Humm, I forgot all about this email. I'll stick it in right now for >>>> 3.10.2. If you don't mind please file a bug so that it isn't forgotten. >>>> >>>> On Wed, Apr 13, 2011 at 2:17 PM, Burlen Loring <[email protected]> wrote: >>>> >>>>> Hi Dave, >>>>> >>>>> What is the status on this? >>>>> >>>>> Burlen >>>>> >>>>> >>>>> On 02/27/2011 02:53 PM, David Partyka wrote: >>>>> >>>>> Thanks Burlen, We'll take a look. >>>>> >>>>> On Sun, Feb 27, 2011 at 5:18 PM, Burlen Loring <[email protected]>wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> While installing ParaView on Nautilus, >>>>>> http://www.nics.tennessee.edu/computing-resources/nautilus, I hit a >>>>>> bug in vtkSocket that prevents ParaView from running on this machine. >>>>>> While >>>>>> tracking this down I uncovered a couple related issues. >>>>>> >>>>>> The main issue is that vtkSocket does not handle EINTR. EINTR occurs >>>>>> when a signal is caught by the application during a blocking socket call. >>>>>> While ParaView does not make use of signals they are used for >>>>>> asynchronous >>>>>> communication by some SGI specific libraries on Nautilus that are linked >>>>>> in >>>>>> with SGI MPI. Because Rank 0 pvserver spends quite a bit of its time >>>>>> blocked >>>>>> in socket calls it only takes a few 10s of seconds for EINTR to occur. >>>>>> When >>>>>> faced with EINTR ParaView silently exits leaving the user wondering what >>>>>> the >>>>>> heck happened. Which brings me to the second issue, a lack of error >>>>>> reporting in vtkSocket. >>>>>> >>>>>> To solve the first issue vtkSocket has to handle EINTR. How EINTR >>>>>> should be handled depends on the specific socket call. For all calls >>>>>> except >>>>>> connect the call can simply be restarted. For EINTR during connect one >>>>>> can't >>>>>> restart the call on all unix, so instead one must block in a select call >>>>>> when connect fails with EINTR. To be portable across Unix one should >>>>>> handle >>>>>> EINTR in all socket calls, even simple ones like set/getsockopt. >>>>>> >>>>>> The second issue of error reporting applies to all socket related >>>>>> errors in general, my feeling is that when a socket call fails vtkSocket >>>>>> should print a message using vtkErrorMacro, errno, and strerror(or >>>>>> windows >>>>>> equivalent) at the point of failure. I think this should be done inside >>>>>> vtkSocket because this is the only place one can safely assume errno has >>>>>> relevant information and vtkSocket has been implemented returning a >>>>>> single >>>>>> error code, -1, so that returning the real error code would change the >>>>>> API >>>>>> and break existing code, including ParaView. Not to mention that the >>>>>> values >>>>>> for error codes are apparently different on windows and unix. >>>>>> >>>>>> I took a stab at fixing these issues, patches attached. I tested them >>>>>> on my workstation, nautilus, and laptop running xp. I ran a dashboard on >>>>>> my >>>>>> linux workstation and didn't see any related issues. Would someone at KW >>>>>> mind taking a look at the changes and see if it could be made permanent? >>>>>> >>>>>> By the way after testing all socket calls for error returns I >>>>>> uncovered a third bug, vtkSocket::Close didn't set the descriptor ivar >>>>>> to -1 >>>>>> which resulted in vtkSocket::~vtkSocket calling close on a closed socket. >>>>>> Not a disasterous error, but this reinforces my opinion that the returns >>>>>> should be tested and error messages printed. >>>>>> >>>>>> Thanks >>>>>> Burlen >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>>> Follow this link to subscribe/unsubscribe: >>>>>> http://www.paraview.org/mailman/listinfo/paraview >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >> >> > >
_______________________________________________ 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 Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
