[Paraview] vtkSocket bugs

[Burlen Loring]

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 <bloring at lbl.gov 
> <mailto:bloring at 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 <http://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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20110413/bfed6713/attachment.htm>