- devel - mailman3.cels.anl.gov

Re: [mpich-devel] Issue with MPI_Error_string() for user-defined codes/clases
by Rob Latham 22 Apr '14

22 Apr '14

On 04/22/2014 04:04 AM, Lisandro Dalcin wrote: > The following simple tests segfaults. A quick fix would be to return > an empty string in MPIR_Err_get_dynerr_string() (file dynerrutil.c), I don't muck around in this code very often, so after thinking about it for a bit, and coming up with another way to do it, I opened a ticket so i could get a second (third, I guess) opinion: https://trac.mpich.org/projects/mpich/ticket/2067 ==rob > e.g: > > diff --git a/src/mpi/errhan/dynerrutil.c b/src/mpi/errhan/dynerrutil.c > index 943e8c3..fb40469 100644 > --- a/src/mpi/errhan/dynerrutil.c > +++ b/src/mpi/errhan/dynerrutil.c > @@ -297,11 +297,13 @@ const char *MPIR_Err_get_dynerr_string( int code ) > if (errcode) { > if (errcode < first_free_code) { > errstr = user_code_msgs[errcode]; > + if (!errstr) errstr = ""; > } > } > else { > if (errclass < first_free_class) { > errstr = user_class_msgs[errclass]; > + if (!errstr) errstr = ""; > } > } > > > [dalcinl@kw2060 ~]$ cat error_string2.c > #include <stdio.h> > #include <mpi.h> > int main(int argc, char *argv[]) > { > int errorclass; > char errorstring[MPI_MAX_ERROR_STRING] = {64,0}; > int slen; > MPI_Init(&argc, &argv); > MPI_Add_error_class(&errorclass); > MPI_Error_string(errorclass, errorstring, &slen); > printf("errorclass:%d errorstring:'%s' len:%d\n", errorclass, > errorstring, slen); > MPI_Finalize(); > return 0; > } -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] detecting mpirun mismatch
by Balaji, Pavan 22 Apr '14

22 Apr '14

Jeff, Do you need to know if it’s Hydra or if it’s a PMI server? Any PMI server can work with any PMI client. Ideally, they’ll negotiate on the PMI version to use, but a bad client/server might assume a particular version. You can make sure it’s a PMI server by checking for PMI environment variables. Either PMI_FD or PMI_PORT will need to be set. — Pavan On Apr 22, 2014, at 4:48 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > Does anyone know of a good way to detect when the user has built an > MPI application with mpicc from implementation A and tries to launch > with mpirun/mpiexec from implementation B? > > I know that inside of the application, I can use either > MPI_Get_library_version or preprocessor info to know what > implementation I am using. But can I discover anything about mpirun > inside of the application? Is there anything in the environment that > I can query to know if my PM is Hydra, for example? If not, can that > be added? > > This is a relatively common user error that leads to very bad things > in some cases so it would be nice to be able to detect it and throw a > warning/error. > > Thanks, > > Jeff > > -- > Jeff Hammond > jeff.science(a)gmail.com

1 0

detecting mpirun mismatch
by Jeff Hammond 22 Apr '14

22 Apr '14

Does anyone know of a good way to detect when the user has built an MPI application with mpicc from implementation A and tries to launch with mpirun/mpiexec from implementation B? I know that inside of the application, I can use either MPI_Get_library_version or preprocessor info to know what implementation I am using. But can I discover anything about mpirun inside of the application? Is there anything in the environment that I can query to know if my PM is Hydra, for example? If not, can that be added? This is a relatively common user error that leads to very bad things in some cases so it would be nice to be able to detect it and throw a warning/error. Thanks, Jeff -- Jeff Hammond jeff.science(a)gmail.com

1 0

Re: [mpich-devel] Issue with MPI_Error_string() for user-defined codes/clases
by Rob Latham 22 Apr '14

22 Apr '14

On 04/22/2014 04:04 AM, Lisandro Dalcin wrote: > The MPI-3 standard says (pp.354, lines 39-40): > > """ > If MPI_ERROR_STRING is called when no string has been set, it will > return a empty > string (all spaces in Fortran, "" in C). > """ > > The following simple tests segfaults. A quick fix would be to return > an empty string in MPIR_Err_get_dynerr_string() (file dynerrutil.c), > e.g: Now that I look at this a bit more closely, shouldn't user_code_msgs[] and user_class_msgs[] be initialized to "", not 0 ? That messes up some other assumptions of the errorcode handling code, though.. ==rob > > diff --git a/src/mpi/errhan/dynerrutil.c b/src/mpi/errhan/dynerrutil.c > index 943e8c3..fb40469 100644 > --- a/src/mpi/errhan/dynerrutil.c > +++ b/src/mpi/errhan/dynerrutil.c > @@ -297,11 +297,13 @@ const char *MPIR_Err_get_dynerr_string( int code ) > if (errcode) { > if (errcode < first_free_code) { > errstr = user_code_msgs[errcode]; > + if (!errstr) errstr = ""; > } > } > else { > if (errclass < first_free_class) { > errstr = user_class_msgs[errclass]; > + if (!errstr) errstr = ""; > } > } > > > [dalcinl@kw2060 ~]$ cat error_string2.c > #include <stdio.h> > #include <mpi.h> > int main(int argc, char *argv[]) > { > int errorclass; > char errorstring[MPI_MAX_ERROR_STRING] = {64,0}; > int slen; > MPI_Init(&argc, &argv); > MPI_Add_error_class(&errorclass); > MPI_Error_string(errorclass, errorstring, &slen); > printf("errorclass:%d errorstring:'%s' len:%d\n", errorclass, > errorstring, slen); > MPI_Finalize(); > return 0; > } > > [dalcinl@kw2060 ~]$ mpicc error_string2.c > [dalcinl@kw2060 ~]$ ./a.out > Segmentation fault (core dumped) > > [dalcinl@kw2060 ~]$ valgrind -q ./a.out > ==14176== Invalid read of size 1 > ==14176== at 0x4C6F5E7: MPIU_Strncpy (safestr.c:65) > ==14176== by 0x4C61864: MPIR_Err_get_string (errutil.c:601) > ==14176== by 0x4DA4DB4: PMPI_Error_string (error_string.c:80) > ==14176== by 0x400888: main (in /home/dalcinl/Devel/BUGS-MPI/~/a.out) > ==14176== Address 0x0 is not stack'd, malloc'd or (recently) free'd > ==14176== > ==14176== > ==14176== Process terminating with default action of signal 11 (SIGSEGV) > ==14176== Access not within mapped region at address 0x0 > ==14176== at 0x4C6F5E7: MPIU_Strncpy (safestr.c:65) > ==14176== by 0x4C61864: MPIR_Err_get_string (errutil.c:601) > ==14176== by 0x4DA4DB4: PMPI_Error_string (error_string.c:80) > ==14176== by 0x400888: main (in /home/dalcinl/Devel/BUGS-MPI/~/a.out) > ==14176== If you believe this happened as a result of a stack > ==14176== overflow in your program's main thread (unlikely but > ==14176== possible), you can try to increase the size of the > ==14176== main thread stack using the --main-stacksize= flag. > ==14176== The main thread stack size used in this run was 8720384. > Segmentation fault (core dumped) > > > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] Issue with MPI_Error_string() for user-defined codes/clases
by Rob Latham 22 Apr '14

22 Apr '14

On 04/22/2014 04:04 AM, Lisandro Dalcin wrote: > The MPI-3 standard says (pp.354, lines 39-40): > > """ > If MPI_ERROR_STRING is called when no string has been set, it will > return a empty > string (all spaces in Fortran, "" in C). > """ > > The following simple tests segfaults. A quick fix would be to return > an empty string in MPIR_Err_get_dynerr_string() (file dynerrutil.c), > e.g: Makes sense to me, but maybe Pavan has an issue with buffering? ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] Default print name for MPI-3 C++ datatypes
by Rob Latham 22 Apr '14

22 Apr '14

On 04/22/2014 07:10 AM, Lisandro Dalcin wrote: > The attached patch is so trivial I'm surprised this is not already > fixed. Any chance you missed this email? I pushed this to master just now. thanks for pinging the list again. ==rob > > On 9 April 2014 10:46, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: >> Please review the following trivial patch (also attached), >> >> diff --git a/src/mpi/datatype/type_get_name.c b/src/mpi/datatype/type_get_name.c >> index 07c2f84..e550dfb 100644 >> --- a/src/mpi/datatype/type_get_name.c >> +++ b/src/mpi/datatype/type_get_name.c >> @@ -108,6 +108,12 @@ static mpi_names_t mpi_names[] = { >> type_name_entry(MPI_C_DOUBLE_COMPLEX), >> type_name_entry(MPI_C_LONG_DOUBLE_COMPLEX), >> >> + /* C++ types */ >> + type_name_entry(MPI_CXX_BOOL), >> + type_name_entry(MPI_CXX_FLOAT_COMPLEX), >> + type_name_entry(MPI_CXX_DOUBLE_COMPLEX), >> + type_name_entry(MPI_CXX_LONG_DOUBLE_COMPLEX), >> + >> /* address/offset types */ >> type_name_entry(MPI_AINT), >> type_name_entry(MPI_OFFSET), >> >> -- >> Lisandro Dalcin >> --------------- >> CIMEC (UNL/CONICET) >> Predio CONICET-Santa Fe >> Colectora RN 168 Km 472, Paraje El Pozo >> 3000 Santa Fe, Argentina >> Tel: +54-342-4511594 (ext 1016) >> Tel/Fax: +54-342-4511169 > > > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] Default print name for MPI-3 C++ datatypes
by Jeff Hammond 22 Apr '14

22 Apr '14

If you file trac tickets, the chance of these type of things getting lost is smaller. Do you not have trac account? I thought you did before. Best, Jeff Sent from my iPhone > On Apr 22, 2014, at 7:10 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > > The attached patch is so trivial I'm surprised this is not already > fixed. Any chance you missed this email? > >> On 9 April 2014 10:46, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: >> Please review the following trivial patch (also attached), >> >> diff --git a/src/mpi/datatype/type_get_name.c b/src/mpi/datatype/type_get_name.c >> index 07c2f84..e550dfb 100644 >> --- a/src/mpi/datatype/type_get_name.c >> +++ b/src/mpi/datatype/type_get_name.c >> @@ -108,6 +108,12 @@ static mpi_names_t mpi_names[] = { >> type_name_entry(MPI_C_DOUBLE_COMPLEX), >> type_name_entry(MPI_C_LONG_DOUBLE_COMPLEX), >> >> + /* C++ types */ >> + type_name_entry(MPI_CXX_BOOL), >> + type_name_entry(MPI_CXX_FLOAT_COMPLEX), >> + type_name_entry(MPI_CXX_DOUBLE_COMPLEX), >> + type_name_entry(MPI_CXX_LONG_DOUBLE_COMPLEX), >> + >> /* address/offset types */ >> type_name_entry(MPI_AINT), >> type_name_entry(MPI_OFFSET), >> >> -- >> Lisandro Dalcin >> --------------- >> CIMEC (UNL/CONICET) >> Predio CONICET-Santa Fe >> Colectora RN 168 Km 472, Paraje El Pozo >> 3000 Santa Fe, Argentina >> Tel: +54-342-4511594 (ext 1016) >> Tel/Fax: +54-342-4511169 > > > > -- > Lisandro Dalcin > --------------- > CIMEC (UNL/CONICET) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1016) > Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] Default print name for MPI-3 C++ datatypes
by Lisandro Dalcin 22 Apr '14

22 Apr '14

The attached patch is so trivial I'm surprised this is not already fixed. Any chance you missed this email? On 9 April 2014 10:46, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > Please review the following trivial patch (also attached), > > diff --git a/src/mpi/datatype/type_get_name.c b/src/mpi/datatype/type_get_name.c > index 07c2f84..e550dfb 100644 > --- a/src/mpi/datatype/type_get_name.c > +++ b/src/mpi/datatype/type_get_name.c > @@ -108,6 +108,12 @@ static mpi_names_t mpi_names[] = { > type_name_entry(MPI_C_DOUBLE_COMPLEX), > type_name_entry(MPI_C_LONG_DOUBLE_COMPLEX), > > + /* C++ types */ > + type_name_entry(MPI_CXX_BOOL), > + type_name_entry(MPI_CXX_FLOAT_COMPLEX), > + type_name_entry(MPI_CXX_DOUBLE_COMPLEX), > + type_name_entry(MPI_CXX_LONG_DOUBLE_COMPLEX), > + > /* address/offset types */ > type_name_entry(MPI_AINT), > type_name_entry(MPI_OFFSET), > > -- > Lisandro Dalcin > --------------- > CIMEC (UNL/CONICET) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1016) > Tel/Fax: +54-342-4511169 -- Lisandro Dalcin --------------- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

1 0

Issue with MPI_Error_string() for user-defined codes/clases
by Lisandro Dalcin 22 Apr '14

22 Apr '14

The MPI-3 standard says (pp.354, lines 39-40): """ If MPI_ERROR_STRING is called when no string has been set, it will return a empty string (all spaces in Fortran, "" in C). """ The following simple tests segfaults. A quick fix would be to return an empty string in MPIR_Err_get_dynerr_string() (file dynerrutil.c), e.g: diff --git a/src/mpi/errhan/dynerrutil.c b/src/mpi/errhan/dynerrutil.c index 943e8c3..fb40469 100644 --- a/src/mpi/errhan/dynerrutil.c +++ b/src/mpi/errhan/dynerrutil.c @@ -297,11 +297,13 @@ const char *MPIR_Err_get_dynerr_string( int code ) if (errcode) { if (errcode < first_free_code) { errstr = user_code_msgs[errcode]; + if (!errstr) errstr = ""; } } else { if (errclass < first_free_class) { errstr = user_class_msgs[errclass]; + if (!errstr) errstr = ""; } } [dalcinl@kw2060 ~]$ cat error_string2.c #include <stdio.h> #include <mpi.h> int main(int argc, char *argv[]) { int errorclass; char errorstring[MPI_MAX_ERROR_STRING] = {64,0}; int slen; MPI_Init(&argc, &argv); MPI_Add_error_class(&errorclass); MPI_Error_string(errorclass, errorstring, &slen); printf("errorclass:%d errorstring:'%s' len:%d\n", errorclass, errorstring, slen); MPI_Finalize(); return 0; } [dalcinl@kw2060 ~]$ mpicc error_string2.c [dalcinl@kw2060 ~]$ ./a.out Segmentation fault (core dumped) [dalcinl@kw2060 ~]$ valgrind -q ./a.out ==14176== Invalid read of size 1 ==14176== at 0x4C6F5E7: MPIU_Strncpy (safestr.c:65) ==14176== by 0x4C61864: MPIR_Err_get_string (errutil.c:601) ==14176== by 0x4DA4DB4: PMPI_Error_string (error_string.c:80) ==14176== by 0x400888: main (in /home/dalcinl/Devel/BUGS-MPI/~/a.out) ==14176== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==14176== ==14176== ==14176== Process terminating with default action of signal 11 (SIGSEGV) ==14176== Access not within mapped region at address 0x0 ==14176== at 0x4C6F5E7: MPIU_Strncpy (safestr.c:65) ==14176== by 0x4C61864: MPIR_Err_get_string (errutil.c:601) ==14176== by 0x4DA4DB4: PMPI_Error_string (error_string.c:80) ==14176== by 0x400888: main (in /home/dalcinl/Devel/BUGS-MPI/~/a.out) ==14176== If you believe this happened as a result of a stack ==14176== overflow in your program's main thread (unlikely but ==14176== possible), you can try to increase the size of the ==14176== main thread stack using the --main-stacksize= flag. ==14176== The main thread stack size used in this run was 8720384. Segmentation fault (core dumped) -- Lisandro Dalcin --------------- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] Should MPI_{Comm|Win|File}_Set_info(..., MPI_INFO_NULL) fail ?
by Rajeev Thakur 09 Apr '14

09 Apr '14

It is not clear that passing MPI_INFO_NULL should result in resetting hints to default. For example, pg 248 at the bottom says "When an info object that specifies a subset of valid hints is passed to MPI_COMM_SET_INFO, there will be no effect on previously set or defaulted hints that the info does not specify." So if MPI_INFO_NULL is passed, at best nothing should happen. But the function definition doesn't say that INFO_NULL is a valid parameter. The behavior you are seeing is because comm_set_info uses a different (probably buggy) null test MPIR_ERRTEST_ARGNULL(info, "info", mpi_errno); whereas win_set_info uses MPIR_ERRTEST_INFO(info, mpi_errno); and I/O uses something else :-). Rajeev On Apr 9, 2014, at 4:51 AM, Lisandro Dalcin <dalcinl(a)gmail.com> wrote: > Right now, it success for Comm but fails for Win and File. IMHO, all > should success, this should be a way for users to ask the > implementation "please, reset the info hints to whatever the defaults > are". > > If you decide they should fail, then the Comm case needs a fix to > generate an error. > > $ mpicc comm_set_info.c > $ ./a.out > > > $ mpicc win_set_info.c > $ ./a.out > Fatal error in MPI_Win_set_info: Invalid argument, error stack: > MPI_Win_set_info(126): MPI_Win_set_info(win=win=0xa0000000, > info=MPI_INFO_NULL) failed > MPI_Win_set_info(82).: Null MPI_Info > > > $ mpicc file_set_info.c > $ ./a.out > Fatal error in PMPI_Info_dup: Invalid argument, error stack: > PMPI_Info_dup(149): MPI_Info_dup(MPI_INFO_NULL, newinfo=0x7fff58b899c4) failed > PMPI_Info_dup(108): Null MPI_Info > > > PS: Perhaps you have an easy fix for the error message (PMPI -> MPI) > in the last one? > > -- > Lisandro Dalcin > --------------- > CIMEC (UNL/CONICET) > Predio CONICET-Santa Fe > Colectora RN 168 Km 472, Paraje El Pozo > 3000 Santa Fe, Argentina > Tel: +54-342-4511594 (ext 1016) > Tel/Fax: +54-342-4511169 > <comm_set_info.c><file_set_info.c><win_set_info.c>

1 0