Thanks Burlen, We'll take a look. On Sun, Feb 27, 2011 at 5:18 PM, Burlen Loring <blor...@lbl.gov> 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
