[Paraview] vtkSocket bugs

Fri Apr 15 16:28:04 EDT 2011

Looks like David Gobbi's change did the trick. I'll merge that into release
so it will be part of the next releases of ParaView/VTK.

On Fri, Apr 15, 2011 at 2:56 PM, Burlen Loring <bloring at lbl.gov> wrote:

>  That would be great! Thanks Daves.
>
>
> On 04/15/2011 11:46 AM, David Partyka wrote:
>
> Hey Burlen, David Gobbi just made some fixes to this and checked it into
> VTK moments ago.
>
>
> http://vtk.org/gitweb?p=VTK.git;a=commitdiff;h=d2a1fb9c5dd99830ad3cdfb753dcdd0e77268799
>
>  http://www.cdash.org/CDash/viewUpdate.php?buildid=976658
>
>  If the dashboard turns out well you should be off the hook ;-)
>
> On Fri, Apr 15, 2011 at 2:42 PM, Burlen Loring <bloring at lbl.gov> wrote:
>
>>  Hmm,  I had tested it on XP with PV 3.8.1 and didn't have any problems.
>> sorry about that, I'll have to try again.
>>
>> Burlen
>>
>>
>> On 04/14/2011 07:54 PM, David Partyka wrote:
>>
>> Hi Burlen, I had to revert your patch as it doesn't compile on Windows..
>>
>>  You will have to make sure it compiles there as well and resubmit your
>> patch. If you need any help please let me know. Thanks.
>>
>> On Thu, Apr 14, 2011 at 3:51 PM, David Partyka <david.partyka at kitware.com
>> > wrote:
>>
>>> 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/20110415/0d6cf91e/attachment-0001.htm>