April 2014 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] Issue with MPI_Error_string() for user-defined codes/clases
by Lisandro Dalcin 24 Apr '14

24 Apr '14

On 23 April 2014 23:11, Larry Baker <baker(a)usgs.gov> wrote: > Lisandro, > > As a matter of personal taste, I prefer that empty strings be used as > initializers for C strings. One of the things I dislike extremely about C > (and, one of the reasons I think it is so easy in C to write bad code) is > its mixing of integers and pointers and integers and chars. Even though { 0 > } is identical to { "" } when initializing C strings, I find the latter more > informative. I know the C standard specifies that strings are terminated by > the null character, which is elsewhere specified to be a byte with all bits > equal to zero. However, "" is the literal empty string, whereas 0 (or '\0') > is the underlying implementation of the empty string. Are you talking about this single line:? static const char empty_error_string[1] = { 0 }; I guess you are proposing to change it to: static const char empty_error_string[1] = ""; Please note {""} is an array of strings. Perhaps you meant {'\0'}, i.e. the null char literal? Please confirm your concerns were related to that single line of my patch, so I can update the trac ticket. -- 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] Issue with MPI_Error_string() for user-defined codes/clases
by Jeff Hammond 23 Apr '14

23 Apr '14

https://lists.mpich.org/mailman/listinfo/devel This should probably be added to the email footer, btw. Best, Jeff On Wed, Apr 23, 2014 at 3:49 PM, Marco <marcodpc(a)gmail.com> wrote: > how I unsubscribe to this mailing list ? > > Thanks > > > 2014-04-23 22:11 GMT+02:00 Larry Baker <baker(a)usgs.gov>: > >> Lisandro, >> >> As a matter of personal taste, I prefer that empty strings be used as >> initializers for C strings. One of the things I dislike extremely about C >> (and, one of the reasons I think it is so easy in C to write bad code) is >> its mixing of integers and pointers and integers and chars. Even though { 0 >> } is identical to { "" } when initializing C strings, I find the latter more >> informative. I know the C standard specifies that strings are terminated by >> the null character, which is elsewhere specified to be a byte with all bits >> equal to zero. However, "" is the literal empty string, whereas 0 (or '\0') >> is the underlying implementation of the empty string. This is also why I >> prefer to use the C99 NULL macro constant to initialize pointers with the >> nil pointer as opposed to 0 (which gets implicitly cast to a nil pointer of >> the correct size), the implementation of the nil pointer. As I said, >> though, this is all just a matter of taste -- there is no difference in the >> correctness of the code. >> >> Larry Baker >> US Geological Survey >> 650-329-5608 >> baker(a)usgs.gov >> >> >> >> On 23 Apr 2014, at 3:20 AM, Lisandro Dalcin wrote: >> >> On 23 April 2014 00:55, Rob Latham <robl(a)mcs.anl.gov> wrote: >> >> >> >> 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 >> >> >> >> IMHO your patch complicates things too much, I'm still in support of >> this slightly refined version that removes the usage of empty string >> constants (Rob, could you upload this patch to the ticket?): >> >> $ git diff >> diff --git a/src/mpi/errhan/dynerrutil.c b/src/mpi/errhan/dynerrutil.c >> index 943e8c3..2e3bb27 100644 >> --- a/src/mpi/errhan/dynerrutil.c >> +++ b/src/mpi/errhan/dynerrutil.c >> @@ -48,6 +48,7 @@ static const char >> *(user_class_msgs[ERROR_MAX_NCLASS]) = { 0 }; >> static const char *(user_code_msgs[ERROR_MAX_NCODE]) = { 0 }; >> static int first_free_class = 0; >> static int first_free_code = 1; /* code 0 is reserved */ >> +static const char empty_error_string[1] = { 0 }; >> >> /* Forward reference */ >> const char *MPIR_Err_get_dynerr_string( int code ); >> @@ -297,11 +298,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 = empty_error_string; >> } >> } >> else { >> if (errclass < first_free_class) { >> errstr = user_class_msgs[errclass]; >> + if (!errstr) errstr = empty_error_string; >> } >> } >> >> >> >> -- >> 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 >> <error-string.diff> >> >> > -- Jeff Hammond jeff.science(a)gmail.com

1 0

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

23 Apr '14

how I unsubscribe to this mailing list ? Thanks 2014-04-23 22:11 GMT+02:00 Larry Baker <baker(a)usgs.gov>: > Lisandro, > > As a matter of personal taste, I prefer that empty strings be used as > initializers for C strings. One of the things I dislike extremely about C > (and, one of the reasons I think it is so easy in C to write bad code) is > its mixing of integers and pointers and integers and chars. Even though { > 0 } is identical to { "" } when initializing C strings, I find the latter > more informative. I know the C standard specifies that strings are > terminated by the null character, which is elsewhere specified to be a byte > with all bits equal to zero. However, "" *is* the literal empty string, > whereas 0 (or '\0') is the underlying implementation of the empty string. > This is also why I prefer to use the C99 NULL macro constant to initialize > pointers with the *nil* pointer as opposed to 0 (which gets implicitly > cast to a nil pointer of the correct size), the implementation of the nil > pointer. As I said, though, this is all just a matter of taste -- there is > no difference in the correctness of the code. > > Larry Baker > US Geological Survey > 650-329-5608 > baker(a)usgs.gov > > > > On 23 Apr 2014, at 3:20 AM, Lisandro Dalcin wrote: > > On 23 April 2014 00:55, Rob Latham <robl(a)mcs.anl.gov> wrote: > > > > 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 > > > > IMHO your patch complicates things too much, I'm still in support of > this slightly refined version that removes the usage of empty string > constants (Rob, could you upload this patch to the ticket?): > > $ git diff > diff --git a/src/mpi/errhan/dynerrutil.c b/src/mpi/errhan/dynerrutil.c > index 943e8c3..2e3bb27 100644 > --- a/src/mpi/errhan/dynerrutil.c > +++ b/src/mpi/errhan/dynerrutil.c > @@ -48,6 +48,7 @@ static const char > *(user_class_msgs[ERROR_MAX_NCLASS]) = { 0 }; > static const char *(user_code_msgs[ERROR_MAX_NCODE]) = { 0 }; > static int first_free_class = 0; > static int first_free_code = 1; /* code 0 is reserved */ > +static const char empty_error_string[1] = { 0 }; > > /* Forward reference */ > const char *MPIR_Err_get_dynerr_string( int code ); > @@ -297,11 +298,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 = empty_error_string; > } > } > else { > if (errclass < first_free_class) { > errstr = user_class_msgs[errclass]; > + if (!errstr) errstr = empty_error_string; > } > } > > > > -- > 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 > <error-string.diff> > > >

1 0

Re: [mpich-devel] Issue with MPI_Error_string() for user-defined codes/clases
by Larry Baker 23 Apr '14

23 Apr '14

Lisandro, As a matter of personal taste, I prefer that empty strings be used as initializers for C strings. One of the things I dislike extremely about C (and, one of the reasons I think it is so easy in C to write bad code) is its mixing of integers and pointers and integers and chars. Even though { 0 } is identical to { "" } when initializing C strings, I find the latter more informative. I know the C standard specifies that strings are terminated by the null character, which is elsewhere specified to be a byte with all bits equal to zero. However, "" is the literal empty string, whereas 0 (or '\0') is the underlying implementation of the empty string. This is also why I prefer to use the C99 NULL macro constant to initialize pointers with the nil pointer as opposed to 0 (which gets implicitly cast to a nil pointer of the correct size), the implementation of the nil pointer. As I said, though, this is all just a matter of taste -- there is no difference in the correctness of the code. Larry Baker US Geological Survey 650-329-5608 baker(a)usgs.gov On 23 Apr 2014, at 3:20 AM, Lisandro Dalcin wrote: > On 23 April 2014 00:55, Rob Latham <robl(a)mcs.anl.gov> wrote: >> >> >> 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 >> > > IMHO your patch complicates things too much, I'm still in support of > this slightly refined version that removes the usage of empty string > constants (Rob, could you upload this patch to the ticket?): > > $ git diff > diff --git a/src/mpi/errhan/dynerrutil.c b/src/mpi/errhan/dynerrutil.c > index 943e8c3..2e3bb27 100644 > --- a/src/mpi/errhan/dynerrutil.c > +++ b/src/mpi/errhan/dynerrutil.c > @@ -48,6 +48,7 @@ static const char > *(user_class_msgs[ERROR_MAX_NCLASS]) = { 0 }; > static const char *(user_code_msgs[ERROR_MAX_NCODE]) = { 0 }; > static int first_free_class = 0; > static int first_free_code = 1; /* code 0 is reserved */ > +static const char empty_error_string[1] = { 0 }; > > /* Forward reference */ > const char *MPIR_Err_get_dynerr_string( int code ); > @@ -297,11 +298,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 = empty_error_string; > } > } > else { > if (errclass < first_free_class) { > errstr = user_class_msgs[errclass]; > + if (!errstr) errstr = empty_error_string; > } > } > > > > -- > 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 > <error-string.diff>

1 0

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

23 Apr '14

On 04/23/2014 05:20 AM, Lisandro Dalcin wrote: > On 23 April 2014 00:55, Rob Latham <robl(a)mcs.anl.gov> wrote: >> >> >> 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 >> > > IMHO your patch complicates things too much, I'm still in support of > this slightly refined version that removes the usage of empty string > constants (Rob, could you upload this patch to the ticket?): you win! yes, my approach quickly got out of hand. I'll go with your approach after running it through jenkins. ==rob > > $ git diff > diff --git a/src/mpi/errhan/dynerrutil.c b/src/mpi/errhan/dynerrutil.c > index 943e8c3..2e3bb27 100644 > --- a/src/mpi/errhan/dynerrutil.c > +++ b/src/mpi/errhan/dynerrutil.c > @@ -48,6 +48,7 @@ static const char > *(user_class_msgs[ERROR_MAX_NCLASS]) = { 0 }; > static const char *(user_code_msgs[ERROR_MAX_NCODE]) = { 0 }; > static int first_free_class = 0; > static int first_free_code = 1; /* code 0 is reserved */ > +static const char empty_error_string[1] = { 0 }; > > /* Forward reference */ > const char *MPIR_Err_get_dynerr_string( int code ); > @@ -297,11 +298,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 = empty_error_string; > } > } > else { > if (errclass < first_free_class) { > errstr = user_class_msgs[errclass]; > + if (!errstr) errstr = empty_error_string; > } > } > > > -- 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 Kenneth Raffenetti 23 Apr '14

23 Apr '14

Lisandro, I created a Trac user for you. An email should be on its way with your credentials. Ken On 04/23/2014 08:30 AM, Lisandro Dalcin wrote: > On 22 April 2014 20:00, Rob Latham <robl(a)mcs.anl.gov> wrote: >> >> >> 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. >> > > Dear Rob, I want to follow Jeff's advice. > > Could you manage to create a trac account for me? Just in case, could > you check I do not already have one? If I have, I forgot my user name. > >

1 0

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

23 Apr '14

On 22 April 2014 20:00, Rob Latham <robl(a)mcs.anl.gov> wrote: > > > 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. > Dear Rob, I want to follow Jeff's advice. Could you manage to create a trac account for me? Just in case, could you check I do not already have one? If I have, I forgot my user name. -- 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] Issue with MPI_Error_string() for user-defined codes/clases
by Lisandro Dalcin 23 Apr '14

23 Apr '14

On 23 April 2014 00:55, Rob Latham <robl(a)mcs.anl.gov> wrote: > > > 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 > IMHO your patch complicates things too much, I'm still in support of this slightly refined version that removes the usage of empty string constants (Rob, could you upload this patch to the ticket?): $ git diff diff --git a/src/mpi/errhan/dynerrutil.c b/src/mpi/errhan/dynerrutil.c index 943e8c3..2e3bb27 100644 --- a/src/mpi/errhan/dynerrutil.c +++ b/src/mpi/errhan/dynerrutil.c @@ -48,6 +48,7 @@ static const char *(user_class_msgs[ERROR_MAX_NCLASS]) = { 0 }; static const char *(user_code_msgs[ERROR_MAX_NCODE]) = { 0 }; static int first_free_class = 0; static int first_free_code = 1; /* code 0 is reserved */ +static const char empty_error_string[1] = { 0 }; /* Forward reference */ const char *MPIR_Err_get_dynerr_string( int code ); @@ -297,11 +298,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 = empty_error_string; } } else { if (errclass < first_free_class) { errstr = user_class_msgs[errclass]; + if (!errstr) errstr = empty_error_string; } } -- 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] detecting mpirun mismatch
by Dave Goodell (dgoodell) 22 Apr '14

22 Apr '14

On Apr 22, 2014, at 4:58 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > PMI is specific to MPICH-family, right? The problem that was observed > had to do with MPICH/OpenMPI mixing. 'mpirun -np 2' led to two copies > of the application running in serial... I'm pretty sure that Open MPI can speak some flavors of PMI. I don't have any personal experience with using that functionality though, so it may not be very automagical. It might require some special build flags or run-time config. So keep that in mind when considering solutions. Also, don't forget that the "singleton init" case is supported by both OMPI and MPICH, so the absence of PMI_* vars isn't sufficient for you to decide that you were launched by some other MPI implementation's process manager. You actually have to check for other common variables from other launchers / MPI implementations and warn that you know you cannot handle them. I feel like we've had this conversation before on the MPICH lists and decided there was no good solution for this problem... hah, here it is: http://lists.mcs.anl.gov/pipermail/mpich-discuss/2012-February/011756.html I completely concede that Jed's correct here in his response (modulo the "Open MPI is system-installed on Macs", which is no longer true for modern Macs): http://lists.mcs.anl.gov/pipermail/mpich-discuss/2012-February/011757.html -Dave

1 0

Re: [mpich-devel] detecting mpirun mismatch
by Jeff Squyres (jsquyres) 22 Apr '14

22 Apr '14

Is there something we should put between OMPI and MPICH such that one can detect such a mismatch like this? Might be worth thinking about. We get users doing this not infrequently, too. On Apr 22, 2014, at 5:58 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > PMI is specific to MPICH-family, right? The problem that was observed > had to do with MPICH/OpenMPI mixing. 'mpirun -np 2' led to two copies > of the application running in serial... > > If PMI implementations are version specific, should they not export > PMI_VERSION to the environment so bad pairings can be detected? > > Thanks, > > Jeff > > On Tue, Apr 22, 2014 at 4:52 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: >> 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 >> > > > > -- > Jeff Hammond > jeff.science(a)gmail.com -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0