Speaking of which, shouldn't the OB1 error handler send the error message
string that it received as the 4th param to ompi_rte_abort() so that it can be
printed out?
Index: ompi/mca/pml/ob1/pml_ob1.c
===================================================================
--- ompi/mca/pml/ob1/pml_ob1.c (revision 30877)
+++ ompi/mca/pml/ob1/pml_ob1.c (working copy)
@@ -780,7 +780,7 @@
return;
}
#endif /* OPAL_CUDA_SUPPORT */
- ompi_rte_abort(-1, NULL);
+ ompi_rte_abort(-1, btlinfo);
}
#if OPAL_ENABLE_FT_CR == 0
On Feb 27, 2014, at 1:12 PM, Jeff Squyres (jsquyres) <[email protected]> wrote:
> FWIW, the following BTLs all have calls to abort() or ompi_rte_abort() within
> them:
>
> - usnic
> - openib
> - portals4
> - the btl base itself
>
>
> On Feb 27, 2014, at 7:16 AM, Ralph Castain <[email protected]> wrote:
>
>>> The majority of places we call abort in this commit is actually down in a
>>> progress thread. We didn't think it was safe to call the PML error
>>> function in a progress thread -- is that incorrect?
>>
>> If not, then we probably should create some mechanism for doing so. I agree
>> with George that we shouldn't call abort inside a library
>
>
> --
> Jeff Squyres
> [email protected]
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/
>
> _______________________________________________
> devel mailing list
> [email protected]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
--
Jeff Squyres
[email protected]
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
