[Paraview] vtkSocket bugs

Burlen Loring bloring at lbl.gov
Thu Apr 14 14:11:44 EDT 2011


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 <bloring at lbl.gov 
> <mailto:bloring at lbl.gov>> 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 <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/20110414/22b9bee5/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vtkSocket.patch
Type: text/x-patch
Size: 18085 bytes
Desc: not available
URL: <http://www.paraview.org/pipermail/paraview/attachments/20110414/22b9bee5/attachment-0001.bin>


More information about the ParaView mailing list