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 <blor...@lbl.gov
<mailto:blor...@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.part...@kitware.com <mailto:david.part...@kitware.com>> wrote:
Thanks Burlen, This is applied for 3.10.2.
On Thu, Apr 14, 2011 at 2:11 PM, Burlen Loring
<blor...@lbl.gov <mailto:blor...@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
<blor...@lbl.gov <mailto:blor...@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
<blor...@lbl.gov <mailto:blor...@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
_______________________________________________
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
