[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