[Paraview] vtkSocket bugs

[David Partyka]

Thanks Burlen, We'll take a look.

On Sun, Feb 27, 2011 at 5:18 PM, Burlen Loring <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
>
> 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/20110227/58d5c0f5/attachment.htm>