[Paraview] vtkSocket bugs
Burlen Loring
bloring at lbl.gov
Fri Apr 15 14:56:29 EDT 2011
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
> <mailto: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 <mailto: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 <mailto: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 <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/20110415/ba75f494/attachment-0001.htm>
More information about the ParaView
mailing list