June 2019 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] Incorrect error checking?
by Nick Radcliffe 20 Jun '19

20 Jun '19

Hui, The library was built on one of our internal build servers, and run on a different machine of course. But I don't think it's a configure issue. I did a quick test and it's definitely possible for the address of a pointer to not be 8-byte aligned: [nradclif@heron ~]$ cat test_align.c #include <stdlib.h> #include <stdio.h> int main() { int *c; struct { int a; int *b; } __attribute__((packed)) s; c = (int *)&s.b; fprintf(stdout, "c = %p\n", c); return 0; } [nradclif@heron ~]$ ./test_align.x c = 0x7ffe3d4e2c44 I'll have to talk to the user to get more details about their code. Nick Radcliffe  Software Engineer | Cray Inc. 2131 Lindau Ln #1000 | Bloomington, MN 55425 +1-651-605-8864  nradclif(a)cray.com<mailto:[email protected]>  www.cray.com<http://www.cray.com> ________________________________ From: Zhou, Hui <zhouh(a)anl.gov> Sent: Thursday, June 20, 2019 1:13:43 PM To: discuss(a)mpich.org Cc: Nick Radcliffe Subject: Re: [mpich-discuss] Incorrect error checking? That’s interesting. It means the `configure` was finding pointers has to 8-bytes aligned but the user code is having pointers that are 4-byte aligned. I suspect the user did not build the library on the same machine it runs? I am also curious that which architecture actually are not allowing the 4-byte aligned pointers. Nick, is it possible to trace where the questioned mpi library was configured? — Hui Zhou T: 630-252-3430 On Jun 20, 2019, at 1:04 PM, Nick Radcliffe via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Ken, The reason I brought this up is that a user's (valid) code was failing due to this parameter check. It's possible to use an address that's not 8 byte aligned to store a pointer to an int, i.e., int *x; int *y; x = malloc(16); y = &x[1]; I would generally expect y to be 4 byte aligned in the above case. So sometimes this parameter check will cause a correct program to fail, right? Nick Radcliffe  Software Engineer | Cray Inc. 2131 Lindau Ln #1000 | Bloomington, MN 55425 +1-651-605-8864  nradclif(a)cray.com<mailto:[email protected]>  www.cray.com<http://www.cray.com/> ________________________________ From: Raffenetti, Kenneth J. via discuss <discuss(a)mpich.org<mailto:[email protected]>> Sent: Wednesday, June 19, 2019 2:44:40 PM To: discuss(a)mpich.org<mailto:[email protected]> Cc: Raffenetti, Kenneth J. Subject: Re: [mpich-discuss] Incorrect error checking? Upon further thought, it's just trying to catch a common error, and uses alignment to detect it since the type information is lost thru the interface. In testing on x86_64, it doesn't appear that it will catch the intended error. As Thomas pointed out in another reply, there are also some issues with the implementation, though it is correct that we require intptr_t to build MPICH. At the very least, we could patch to use sizeof(void *) vs. sizeof(intptr_t). Or we can still remove the check since the use-case is so narrow. The preprocessor guard also depends on a AC_TRY_RUN that I'd prefer to delete, to be honest. Ken On 6/19/19 9:27 AM, Raffenetti, Kenneth J. via discuss wrote: > Nick, > > I agree this check looks like nonsense. IMO, we can just delete it and > the others like it. I will create a PR. > > Ken > > On 6/18/19 5:25 PM, Nick Radcliffe via discuss wrote: >> I recently noticed that a parameter check in MPII_Win_get_attr looks a >> bit off: >> >> >> /* A common user error is to pass the address of a 4-byte >> * int when the address of a pointer (or an address-sized int) >> * should have been used. We can test for this specific >> * case. Note that this code assumes sizeof(intptr_t) is >> * a power of 2. */ >> if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { >> MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto >> fn_fail, "**attrnotptr"); >> } >> >> >> The comment indicates that the check is testing "attribute_val" to see >> if a pointer to int was passed in, rather than a double pointer or >> pointer to an integer that can store an address. But the check seems to >> only be testing for 8 byte alignment (and failing if not aligned). Am I >> missing something here? >> >> >> >> Nick Radcliffe  Software Engineer| Cray Inc. >> >> 2131 Lindau Ln #1000 | Bloomington, MN55425 >> >> +1-651-605-8864  nradclif(a)cray.com<http://cray.com> <mailto:[email protected]>  www.cray.com >> <http://www.cray.com<http://www.cray.com/>> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org<mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org<mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Incorrect error checking?
by Zhou, Hui 20 Jun '19

20 Jun '19

Right. If you do: int * x; int ** y=&x // or address of any pointer; , you should find the value y either multiple of 4 or 8 (for offending architecture). — Hui Zhou T: 630-252-3430 On Jun 20, 2019, at 1:09 PM, Nick Radcliffe via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Actually, scratch that. My example isn't valid for this case. I'll have to take another look at the user's code to see why it's failing. Nick Radcliffe  Software Engineer | Cray Inc. 2131 Lindau Ln #1000 | Bloomington, MN 55425 +1-651-605-8864  nradclif(a)cray.com<mailto:[email protected]>  www.cray.com<http://www.cray.com/> ________________________________ From: Nick Radcliffe Sent: Thursday, June 20, 2019 1:04:34 PM To: discuss(a)mpich.org<mailto:[email protected]> Cc: Raffenetti, Kenneth J. Subject: Re: [mpich-discuss] Incorrect error checking? Ken, The reason I brought this up is that a user's (valid) code was failing due to this parameter check. It's possible to use an address that's not 8 byte aligned to store a pointer to an int, i.e., int *x; int *y; x = malloc(16); y = &x[1]; I would generally expect y to be 4 byte aligned in the above case. So sometimes this parameter check will cause a correct program to fail, right? Nick Radcliffe  Software Engineer | Cray Inc. 2131 Lindau Ln #1000 | Bloomington, MN 55425 +1-651-605-8864  nradclif(a)cray.com<mailto:[email protected]>  www.cray.com<http://www.cray.com/> ________________________________ From: Raffenetti, Kenneth J. via discuss <discuss(a)mpich.org<mailto:[email protected]>> Sent: Wednesday, June 19, 2019 2:44:40 PM To: discuss(a)mpich.org<mailto:[email protected]> Cc: Raffenetti, Kenneth J. Subject: Re: [mpich-discuss] Incorrect error checking? Upon further thought, it's just trying to catch a common error, and uses alignment to detect it since the type information is lost thru the interface. In testing on x86_64, it doesn't appear that it will catch the intended error. As Thomas pointed out in another reply, there are also some issues with the implementation, though it is correct that we require intptr_t to build MPICH. At the very least, we could patch to use sizeof(void *) vs. sizeof(intptr_t). Or we can still remove the check since the use-case is so narrow. The preprocessor guard also depends on a AC_TRY_RUN that I'd prefer to delete, to be honest. Ken On 6/19/19 9:27 AM, Raffenetti, Kenneth J. via discuss wrote: > Nick, > > I agree this check looks like nonsense. IMO, we can just delete it and > the others like it. I will create a PR. > > Ken > > On 6/18/19 5:25 PM, Nick Radcliffe via discuss wrote: >> I recently noticed that a parameter check in MPII_Win_get_attr looks a >> bit off: >> >> >> /* A common user error is to pass the address of a 4-byte >> * int when the address of a pointer (or an address-sized int) >> * should have been used. We can test for this specific >> * case. Note that this code assumes sizeof(intptr_t) is >> * a power of 2. */ >> if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { >> MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto >> fn_fail, "**attrnotptr"); >> } >> >> >> The comment indicates that the check is testing "attribute_val" to see >> if a pointer to int was passed in, rather than a double pointer or >> pointer to an integer that can store an address. But the check seems to >> only be testing for 8 byte alignment (and failing if not aligned). Am I >> missing something here? >> >> >> >> Nick Radcliffe  Software Engineer| Cray Inc. >> >> 2131 Lindau Ln #1000 | Bloomington, MN55425 >> >> +1-651-605-8864  nradclif(a)cray.com<http://cray.com> <mailto:[email protected]>  www.cray.com >> <http://www.cray.com<http://www.cray.com/>> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org<mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org<mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Incorrect error checking?
by Zhou, Hui 20 Jun '19

20 Jun '19

That’s interesting. It means the `configure` was finding pointers has to 8-bytes aligned but the user code is having pointers that are 4-byte aligned. I suspect the user did not build the library on the same machine it runs? I am also curious that which architecture actually are not allowing the 4-byte aligned pointers. Nick, is it possible to trace where the questioned mpi library was configured? — Hui Zhou T: 630-252-3430 On Jun 20, 2019, at 1:04 PM, Nick Radcliffe via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: Ken, The reason I brought this up is that a user's (valid) code was failing due to this parameter check. It's possible to use an address that's not 8 byte aligned to store a pointer to an int, i.e., int *x; int *y; x = malloc(16); y = &x[1]; I would generally expect y to be 4 byte aligned in the above case. So sometimes this parameter check will cause a correct program to fail, right? Nick Radcliffe  Software Engineer | Cray Inc. 2131 Lindau Ln #1000 | Bloomington, MN 55425 +1-651-605-8864  nradclif(a)cray.com<mailto:[email protected]>  www.cray.com<http://www.cray.com/> ________________________________ From: Raffenetti, Kenneth J. via discuss <discuss(a)mpich.org<mailto:[email protected]>> Sent: Wednesday, June 19, 2019 2:44:40 PM To: discuss(a)mpich.org<mailto:[email protected]> Cc: Raffenetti, Kenneth J. Subject: Re: [mpich-discuss] Incorrect error checking? Upon further thought, it's just trying to catch a common error, and uses alignment to detect it since the type information is lost thru the interface. In testing on x86_64, it doesn't appear that it will catch the intended error. As Thomas pointed out in another reply, there are also some issues with the implementation, though it is correct that we require intptr_t to build MPICH. At the very least, we could patch to use sizeof(void *) vs. sizeof(intptr_t). Or we can still remove the check since the use-case is so narrow. The preprocessor guard also depends on a AC_TRY_RUN that I'd prefer to delete, to be honest. Ken On 6/19/19 9:27 AM, Raffenetti, Kenneth J. via discuss wrote: > Nick, > > I agree this check looks like nonsense. IMO, we can just delete it and > the others like it. I will create a PR. > > Ken > > On 6/18/19 5:25 PM, Nick Radcliffe via discuss wrote: >> I recently noticed that a parameter check in MPII_Win_get_attr looks a >> bit off: >> >> >> /* A common user error is to pass the address of a 4-byte >> * int when the address of a pointer (or an address-sized int) >> * should have been used. We can test for this specific >> * case. Note that this code assumes sizeof(intptr_t) is >> * a power of 2. */ >> if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { >> MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto >> fn_fail, "**attrnotptr"); >> } >> >> >> The comment indicates that the check is testing "attribute_val" to see >> if a pointer to int was passed in, rather than a double pointer or >> pointer to an integer that can store an address. But the check seems to >> only be testing for 8 byte alignment (and failing if not aligned). Am I >> missing something here? >> >> >> >> Nick Radcliffe  Software Engineer| Cray Inc. >> >> 2131 Lindau Ln #1000 | Bloomington, MN55425 >> >> +1-651-605-8864  nradclif(a)cray.com<http://cray.com> <mailto:[email protected]>  www.cray.com >> <http://www.cray.com<http://www.cray.com/>> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org<mailto:[email protected]> >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org<mailto:[email protected]> > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Incorrect error checking?
by Nick Radcliffe 20 Jun '19

20 Jun '19

Actually, scratch that. My example isn't valid for this case. I'll have to take another look at the user's code to see why it's failing. Nick Radcliffe  Software Engineer | Cray Inc. 2131 Lindau Ln #1000 | Bloomington, MN 55425 +1-651-605-8864  nradclif(a)cray.com<mailto:[email protected]>  www.cray.com<http://www.cray.com> ________________________________ From: Nick Radcliffe Sent: Thursday, June 20, 2019 1:04:34 PM To: discuss(a)mpich.org Cc: Raffenetti, Kenneth J. Subject: Re: [mpich-discuss] Incorrect error checking? Ken, The reason I brought this up is that a user's (valid) code was failing due to this parameter check. It's possible to use an address that's not 8 byte aligned to store a pointer to an int, i.e., int *x; int *y; x = malloc(16); y = &x[1]; I would generally expect y to be 4 byte aligned in the above case. So sometimes this parameter check will cause a correct program to fail, right? Nick Radcliffe  Software Engineer | Cray Inc. 2131 Lindau Ln #1000 | Bloomington, MN 55425 +1-651-605-8864  nradclif(a)cray.com<mailto:[email protected]>  www.cray.com<http://www.cray.com> ________________________________ From: Raffenetti, Kenneth J. via discuss <discuss(a)mpich.org> Sent: Wednesday, June 19, 2019 2:44:40 PM To: discuss(a)mpich.org Cc: Raffenetti, Kenneth J. Subject: Re: [mpich-discuss] Incorrect error checking? Upon further thought, it's just trying to catch a common error, and uses alignment to detect it since the type information is lost thru the interface. In testing on x86_64, it doesn't appear that it will catch the intended error. As Thomas pointed out in another reply, there are also some issues with the implementation, though it is correct that we require intptr_t to build MPICH. At the very least, we could patch to use sizeof(void *) vs. sizeof(intptr_t). Or we can still remove the check since the use-case is so narrow. The preprocessor guard also depends on a AC_TRY_RUN that I'd prefer to delete, to be honest. Ken On 6/19/19 9:27 AM, Raffenetti, Kenneth J. via discuss wrote: > Nick, > > I agree this check looks like nonsense. IMO, we can just delete it and > the others like it. I will create a PR. > > Ken > > On 6/18/19 5:25 PM, Nick Radcliffe via discuss wrote: >> I recently noticed that a parameter check in MPII_Win_get_attr looks a >> bit off: >> >> >> /* A common user error is to pass the address of a 4-byte >> * int when the address of a pointer (or an address-sized int) >> * should have been used. We can test for this specific >> * case. Note that this code assumes sizeof(intptr_t) is >> * a power of 2. */ >> if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { >> MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto >> fn_fail, "**attrnotptr"); >> } >> >> >> The comment indicates that the check is testing "attribute_val" to see >> if a pointer to int was passed in, rather than a double pointer or >> pointer to an integer that can store an address. But the check seems to >> only be testing for 8 byte alignment (and failing if not aligned). Am I >> missing something here? >> >> >> >> Nick Radcliffe  Software Engineer| Cray Inc. >> >> 2131 Lindau Ln #1000 | Bloomington, MN55425 >> >> +1-651-605-8864  nradclif(a)cray.com <mailto:[email protected]>  www.cray.com >> <http://www.cray.com> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Incorrect error checking?
by Nick Radcliffe 20 Jun '19

20 Jun '19

Ken, The reason I brought this up is that a user's (valid) code was failing due to this parameter check. It's possible to use an address that's not 8 byte aligned to store a pointer to an int, i.e., int *x; int *y; x = malloc(16); y = &x[1]; I would generally expect y to be 4 byte aligned in the above case. So sometimes this parameter check will cause a correct program to fail, right? Nick Radcliffe  Software Engineer | Cray Inc. 2131 Lindau Ln #1000 | Bloomington, MN 55425 +1-651-605-8864  nradclif(a)cray.com<mailto:[email protected]>  www.cray.com<http://www.cray.com> ________________________________ From: Raffenetti, Kenneth J. via discuss <discuss(a)mpich.org> Sent: Wednesday, June 19, 2019 2:44:40 PM To: discuss(a)mpich.org Cc: Raffenetti, Kenneth J. Subject: Re: [mpich-discuss] Incorrect error checking? Upon further thought, it's just trying to catch a common error, and uses alignment to detect it since the type information is lost thru the interface. In testing on x86_64, it doesn't appear that it will catch the intended error. As Thomas pointed out in another reply, there are also some issues with the implementation, though it is correct that we require intptr_t to build MPICH. At the very least, we could patch to use sizeof(void *) vs. sizeof(intptr_t). Or we can still remove the check since the use-case is so narrow. The preprocessor guard also depends on a AC_TRY_RUN that I'd prefer to delete, to be honest. Ken On 6/19/19 9:27 AM, Raffenetti, Kenneth J. via discuss wrote: > Nick, > > I agree this check looks like nonsense. IMO, we can just delete it and > the others like it. I will create a PR. > > Ken > > On 6/18/19 5:25 PM, Nick Radcliffe via discuss wrote: >> I recently noticed that a parameter check in MPII_Win_get_attr looks a >> bit off: >> >> >> /* A common user error is to pass the address of a 4-byte >> * int when the address of a pointer (or an address-sized int) >> * should have been used. We can test for this specific >> * case. Note that this code assumes sizeof(intptr_t) is >> * a power of 2. */ >> if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { >> MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto >> fn_fail, "**attrnotptr"); >> } >> >> >> The comment indicates that the check is testing "attribute_val" to see >> if a pointer to int was passed in, rather than a double pointer or >> pointer to an integer that can store an address. But the check seems to >> only be testing for 8 byte alignment (and failing if not aligned). Am I >> missing something here? >> >> >> >> Nick Radcliffe  Software Engineer| Cray Inc. >> >> 2131 Lindau Ln #1000 | Bloomington, MN55425 >> >> +1-651-605-8864  nradclif(a)cray.com <mailto:[email protected]>  www.cray.com >> <http://www.cray.com> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Incorrect error checking?
by Raffenetti, Kenneth J. 19 Jun '19

19 Jun '19

Upon further thought, it's just trying to catch a common error, and uses alignment to detect it since the type information is lost thru the interface. In testing on x86_64, it doesn't appear that it will catch the intended error. As Thomas pointed out in another reply, there are also some issues with the implementation, though it is correct that we require intptr_t to build MPICH. At the very least, we could patch to use sizeof(void *) vs. sizeof(intptr_t). Or we can still remove the check since the use-case is so narrow. The preprocessor guard also depends on a AC_TRY_RUN that I'd prefer to delete, to be honest. Ken On 6/19/19 9:27 AM, Raffenetti, Kenneth J. via discuss wrote: > Nick, > > I agree this check looks like nonsense. IMO, we can just delete it and > the others like it. I will create a PR. > > Ken > > On 6/18/19 5:25 PM, Nick Radcliffe via discuss wrote: >> I recently noticed that a parameter check in MPII_Win_get_attr looks a >> bit off: >> >> >> /* A common user error is to pass the address of a 4-byte >> * int when the address of a pointer (or an address-sized int) >> * should have been used. We can test for this specific >> * case. Note that this code assumes sizeof(intptr_t) is >> * a power of 2. */ >> if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { >> MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto >> fn_fail, "**attrnotptr"); >> } >> >> >> The comment indicates that the check is testing "attribute_val" to see >> if a pointer to int was passed in, rather than a double pointer or >> pointer to an integer that can store an address. But the check seems to >> only be testing for 8 byte alignment (and failing if not aligned). Am I >> missing something here? >> >> >> >> Nick Radcliffe  Software Engineer| Cray Inc. >> >> 2131 Lindau Ln #1000 | Bloomington, MN55425 >> >> +1-651-605-8864  nradclif(a)cray.com <mailto:[email protected]>  www.cray.com >> <http://www.cray.com> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] Incorrect error checking?
by Raffenetti, Kenneth J. 19 Jun '19

19 Jun '19

Nick, I agree this check looks like nonsense. IMO, we can just delete it and the others like it. I will create a PR. Ken On 6/18/19 5:25 PM, Nick Radcliffe via discuss wrote: > I recently noticed that a parameter check in MPII_Win_get_attr looks a > bit off: > > > /* A common user error is to pass the address of a 4-byte > * int when the address of a pointer (or an address-sized int) > * should have been used. We can test for this specific > * case. Note that this code assumes sizeof(intptr_t) is > * a power of 2. */ > if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { > MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto > fn_fail, "**attrnotptr"); > } > > > The comment indicates that the check is testing "attribute_val" to see > if a pointer to int was passed in, rather than a double pointer or > pointer to an integer that can store an address. But the check seems to > only be testing for 8 byte alignment (and failing if not aligned). Am I > missing something here? > > > > Nick Radcliffe  Software Engineer| Cray Inc. > > 2131 Lindau Ln #1000 | Bloomington, MN55425 > > +1-651-605-8864  nradclif(a)cray.com <mailto:[email protected]>  www.cray.com > <http://www.cray.com> > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0

Re: [mpich-discuss] Incorrect error checking?
by Thomas Jahns 19 Jun '19

19 Jun '19

Hello, On 6/19/19 12:25 AM, Nick Radcliffe via discuss wrote: > I recently noticed that a parameter check in MPII_Win_get_attr looks a > bit off: > > > /* A common user error is to pass the address of a 4-byte > * int when the address of a pointer (or an address-sized int) > * should have been used. We can test for this specific > * case. Note that this code assumes sizeof(intptr_t) is > * a power of 2. */ > if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { > MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto > fn_fail, "**attrnotptr"); > } > > > The comment indicates that the check is testing "attribute_val" to see > if a pointer to int was passed in, rather than a double pointer or > pointer to an integer that can store an address. But the check seems to > only be testing for 8 byte alignment (and failing if not aligned). Am I > missing something here? There is more to be discussed here: * you are correct to observe that the test is only for alignment to sizeof(intptr_t) (which on LP64 machines would typically be 8) but also: * the code assumes sizeof(intptr_t) == sizeof(any *) which might not be true on systems implementing the additional correctness checks of llvm SoftBound + CETS * intptr_t might not even exist (although I assume mpich would not build on such platforms for other reasons anyway). * int might indeed be address-sized, i.e. the check adds nothing of value on 32-bit platforms. From my point-of-view this is exactly the kind of quick hack that riddles "modern" software. Thomas

1 0

Incorrect error checking?
by Nick Radcliffe 18 Jun '19

18 Jun '19

I recently noticed that a parameter check in MPII_Win_get_attr looks a bit off: /* A common user error is to pass the address of a 4-byte * int when the address of a pointer (or an address-sized int) * should have been used. We can test for this specific * case. Note that this code assumes sizeof(intptr_t) is * a power of 2. */ if ((intptr_t) attribute_val & (sizeof(intptr_t) - 1)) { MPIR_ERR_SETANDSTMT(mpi_errno, MPI_ERR_ARG, goto fn_fail, "**attrnotptr"); } The comment indicates that the check is testing "attribute_val" to see if a pointer to int was passed in, rather than a double pointer or pointer to an integer that can store an address. But the check seems to only be testing for 8 byte alignment (and failing if not aligned). Am I missing something here? Nick Radcliffe  Software Engineer | Cray Inc. 2131 Lindau Ln #1000 | Bloomington, MN 55425 +1-651-605-8864  nradclif(a)cray.com<mailto:[email protected]>  www.cray.com<http://www.cray.com>

1 0

Re: [mpich-discuss] error with MPI_Reduce running cpi
by Zhou, Hui 17 Jun '19

17 Jun '19

The error message says process 0 tried to connect to process 1 and the connection is refused. Common reason is firewall rules. The processes listen on a random port such as 23456, so even when ssh works (port 22), the other ports may be still blocked. — Hui Zhou On Jun 17, 2019, at 11:28 AM, Jinang_Shah <sjinang(a)iitk.ac.in<mailto:[email protected]>> wrote: 1) $ ./configure --prefix=/users/misc/sjinang/mpich-install 2) No. It is showing an error : mpiexec -n 2 -f hostfile ./mpi/mpich-3.3.1/examples/send_recv Fatal error in PMPI_Send: Unknown error class, error stack: PMPI_Send(159).............: MPI_Send(buf=0x7ffe5d59e2a4, count=1, MPI_INT, dest=1, tag=0, MPI_COMM_WORLD) failed MPID_nem_tcp_connpoll(1845): Communication error with rank 1: Connection refused 3) I have done ssh from both the sides and its working fine. So now can you see the problem... Thanks. On 17-06-2019 21:28, Zhou, Hui wrote: Hi Jinang_Shah, Could you list your configure line ( try `head config.log`)? If you try a simple example where process 0 sends a short message to process 1, would you result in similar error? Can csews1 and csews2 connect to each other freely, i.e. is there firewall, router, etc. between these two hosts? — Hui Zhou On Jun 17, 2019, at 10:11 AM, Jinang_Shah via discuss <discuss(a)mpich.org<mailto:[email protected]>> wrote: $ mpiexec -n 2 -f hostfile ./mpi/mpich-3.3.1/examples/cpi Process 1 of 2 is on csews2 Process 0 of 2 is on csews1 Fatal error in PMPI_Reduce: Unknown error class, error stack: PMPI_Reduce(523)................: MPI_Reduce(sbuf=0x7ffeab580c10, rbuf=0x7ffeab580c18, count=1, datatype=MPI_DOUBLE, op=MPI_SUM, root=0, comm=MPI_COMM_WORLD) failed PMPI_Reduce(509)................: MPIR_Reduce_impl(316)...........: MPIR_Reduce_intra_auto(231).....: MPIR_Reduce_intra_binomial(125).: MPIDI_CH3U_Recvq_FDU_or_AEP(629): Communication error with rank 1 Can anyone explain this error and how to overcome it.I have installed just MPICH and not HYDRA package. By the way this same command works fine with hello program the one where each node says their identity. _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0