Thanks Nicolas for pointing out three types of errors for me, <div>Thanks Reuti, the link is very interesting and rich in data.</div><div><br></div><div>By the way, i did read the info you all advised, and it seems that a bad and UB way of failsafing the whole cluster is assigning a simple return error code handler, and then ignoring the client node return values. </div>
<div><br></div><div><font color="#000000"><font face="'Times New Roman'"><font size="3">MPI_Errhandler_set(MPI_COMM_WORLD, MPI_ERRORS_RETURN);</font></font></font></div><div><font class="Apple-style-span" face="'Times New Roman'"><span class="Apple-style-span" style="font-size: medium;"><br>
</span></font></div><div><br><div class="gmail_quote">2011/1/29 Reuti <span dir="ltr"><<a href="mailto:reuti@staff.uni-marburg.de">reuti@staff.uni-marburg.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Am 29.01.2011 um 20:21 schrieb Eugene N:<br>
<div class="im"><br>
> Hello<br>
><br>
> Pavan and Nicolas, thank you very much, I see the point in making even the smallest error fatal, i just have a little trouble understanding the error landscape by an large.<br>
><br>
> I mean, i doubt that mpi error handler will handle errors that are not coming from mpi context.<br>
><br>
> For example, i painstakingly debugged all my mpi calls, so lets asume its all quite on the MPI front, but i cant wouch for a certain library that does minor work that has nothing to do with message passing.<br>
><br>
> I dont want my node calling all rank abort if it segfaults, i mean, if the cause of the error would have nothing to do with mpi, how can i safeguard myself from such troubles?<br>
<br>
</div>There was a similar discussion on the Open MPI list. If one rank crashes for whatever reason, you have to take actions on your own, as long as the used MPI library supports some kind of fault tolerance:<br>
<br>
<a href="http://www.open-mpi.org/community/lists/users/2011/01/15440.php" target="_blank">http://www.open-mpi.org/community/lists/users/2011/01/15440.php</a><br>
<font color="#888888"><br>
-- Reuti<br>
</font><div><div></div><div class="h5"><br>
<br>
> Eugene<br>
><br>
><br>
> 2011/1/29 Pavan Balaji <<a href="mailto:balaji@mcs.anl.gov">balaji@mcs.anl.gov</a>><br>
><br>
> There are also some notes in the README in 1.3.2rc1 describing how to use errors returned by MPI functions, what you can expect, and what you can't.<br>
><br>
> -- Pavan<br>
><br>
><br>
> On 01/29/2011 12:06 PM, Nicolas Rosner wrote:<br>
> Let's suppose you're running a simple MPI program, one communicator,<br>
> ten ranks or so. Now imagine rank 7 hits an off-by-one bug, trespasses<br>
> the end of some array and segfaults.<br>
><br>
> If, by default, your whole program dies immediately, then what? You<br>
> look at the logs, think, insert a few printfs, then track the the<br>
> off-by-one in a couple of minutes.<br>
><br>
> If instead the rest just moves on with a dead rank 7, you end up with<br>
> a half-dead system that will eventually collapse anyway, misleading<br>
> symptoms and a tenfold increase in solution time. Worse, it might even<br>
> not collapse, hiding a bug that will be much harder to track down and<br>
> fix in the future when you don't even remember writing that code.<br>
><br>
> MPICH2 allows you to implement a certain level of runtime fault<br>
> tolerance; I hear future versions will allow a lot more. But<br>
> remember: there is no free lunch -- if you want to write a robust<br>
> system, you'll need to write error handlers that actually handle<br>
> errors robustly.<br>
><br>
> Until you do so, keeping all local fatal errors globally fatal is<br>
> wise. My .02, at least.<br>
><br>
> (Try looking up MPI_ERRORS_ARE_FATAL.)<br>
><br>
> Regards,<br>
> Nicolás<br>
><br>
><br>
><br>
> On Sat, Jan 29, 2011 at 5:54 AM, Eugene N<<a href="mailto:neverov.biks.07.1@gmail.com">neverov.biks.07.1@gmail.com</a>> wrote:<br>
> Hi<br>
> is it true that even if my most humble mpich2 client node will abort, all my<br>
> claster will go down? How can i cure it?<br>
> Thanks,<br>
> Eugene<br>
> _______________________________________________<br>
> mpich-discuss mailing list<br>
> <a href="mailto:mpich-discuss@mcs.anl.gov">mpich-discuss@mcs.anl.gov</a><br>
> <a href="https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss</a><br>
><br>
><br>
> _______________________________________________<br>
> mpich-discuss mailing list<br>
> <a href="mailto:mpich-discuss@mcs.anl.gov">mpich-discuss@mcs.anl.gov</a><br>
> <a href="https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss</a><br>
><br>
> --<br>
> Pavan Balaji<br>
> <a href="http://www.mcs.anl.gov/~balaji" target="_blank">http://www.mcs.anl.gov/~balaji</a><br>
><br>
> _______________________________________________<br>
> mpich-discuss mailing list<br>
> <a href="mailto:mpich-discuss@mcs.anl.gov">mpich-discuss@mcs.anl.gov</a><br>
> <a href="https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss</a><br>
><br>
> _______________________________________________<br>
> mpich-discuss mailing list<br>
> <a href="mailto:mpich-discuss@mcs.anl.gov">mpich-discuss@mcs.anl.gov</a><br>
> <a href="https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss</a><br>
<br>
_______________________________________________<br>
mpich-discuss mailing list<br>
<a href="mailto:mpich-discuss@mcs.anl.gov">mpich-discuss@mcs.anl.gov</a><br>
<a href="https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss" target="_blank">https://lists.mcs.anl.gov/mailman/listinfo/mpich-discuss</a><br>
</div></div></blockquote></div><br></div>