[Paraview] vtkSocket bugs

[David Partyka]

Thanks Burlen, This is applied for 3.10.2.

On Thu, Apr 14, 2011 at 2:11 PM, Burlen Loring <bloring at lbl.gov> wrote:

>  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> 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> 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/20110414/a9e8fa89/attachment.htm>