Thanks Burlen, This is applied for 3.10.2.<br><br><div class="gmail_quote">On Thu, Apr 14, 2011 at 2:11 PM, Burlen Loring <span dir="ltr"><<a href="mailto:bloring@lbl.gov">bloring@lbl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div bgcolor="#ffffff" text="#000000">
Thanks Dave,<br>
<br>
Filed the bug report <a href="http://www.paraview.org/Bug/view.php?id=12087" target="_blank">http://www.paraview.org/Bug/view.php?id=12087</a><br>
<br>
I updated the patch for 3.10.0 as well (attached here and on the bug
report).<br><font color="#888888">
<br>
Burlen</font><div><div></div><div class="h5"><br>
<br>
On 04/13/2011 11:24 AM, David Partyka wrote:
<blockquote type="cite">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.<br>
<br>
<div class="gmail_quote">On Wed, Apr 13, 2011 at 2:17 PM, Burlen
Loring <span dir="ltr"><<a href="mailto:bloring@lbl.gov" target="_blank">bloring@lbl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div bgcolor="#ffffff" text="#000000"> Hi Dave,<br>
<br>
What is the status on this?<br>
<font color="#888888"> <br>
Burlen</font>
<div>
<div><br>
<br>
On 02/27/2011 02:53 PM, David Partyka wrote:
<blockquote type="cite">Thanks Burlen, We'll take a
look.<br>
<br>
<div class="gmail_quote">On Sun, Feb 27, 2011 at 5:18
PM, Burlen Loring <span dir="ltr"><<a href="mailto:bloring@lbl.gov" target="_blank">bloring@lbl.gov</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"> Hi,<br>
<br>
While installing ParaView on Nautilus, <a href="http://www.nics.tennessee.edu/computing-resources/nautilus" target="_blank">http://www.nics.tennessee.edu/computing-resources/nautilus</a>,
I hit a bug in vtkSocket that prevents ParaView
from running on this machine. While tracking this
down I uncovered a couple related issues.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
Thanks<br>
<font color="#888888"> Burlen<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font><br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the
ParaView Wiki at: <a href="http://paraview.org/Wiki/ParaView" target="_blank">http://paraview.org/Wiki/ParaView</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br>
<br>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br>