Re: [mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn
Hi Jed, Satish, Comments inline to the code. Cheers, -Fab Jed Brown wrote on Fri, 17 May 2013 at 21:52:38
With MS-MPI 64-bit from HPC Pack 2008 and 2012, MPI_Attr_get returns error code 773 when called from delete_fn on a communicator obtained from MPI_Comm_split.
Signed-off-by: Jed Brown <[email protected]> Signed-off-by: Satish Balay <[email protected]> --- Updated to propagate the error code from MPI_Attr_get.
<snip>
diff --git a/test/mpi/attr/attrdeleteget.c b/test/mpi/attr/attrdeleteget.c new file mode 100644 index 0000000..05afaa4 --- /dev/null +++ b/test/mpi/attr/attrdeleteget.c @@ -0,0 +1,36 @@ +/* -*- Mode: C; c-basic-offset:4 ; indent-tabs-mode:nil ; -*- */ +/* + * + * (C) 2013 by Argonne National Laboratory. + * See COPYRIGHT in top-level directory. + */ + +#include <stdio.h> +#include "mpi.h" +#include "mpitest.h" + +int key = MPI_KEYVAL_INVALID; +char a[100]; + +int delete_fn (MPI_Comm, int, void *, void *); + +int main(int argc,char **argv) +{ + MPI_Comm scomm; + + MTest_Init(&argc,&argv); + MPI_Comm_split(MPI_COMM_WORLD,1,0,&scomm); + MPI_Keyval_create(MPI_NULL_COPY_FN,delete_fn,&key,(void*)0); + MPI_Attr_put(scomm,key,a); + MPI_Comm_free(&scomm);
The communicator handle will become invalid at some point after you call MPI_Comm_free (but before the call returns). I didn't see in the standard any mention of whether using the communicator in the destroy callback is acceptable. There's the usual vague notion of the call to MPI_Comm_free being erroneous if the delete callback fails.
+ MPI_Finalize(); + return 0; +} + +int delete_fn(MPI_Comm comm,int keyval,void *attr_val,void *extra_state) +{ + int flg; + void *ptr; + + return MPI_Attr_get(comm,key,&ptr,&flg);
Why aren't you using attr_val and extra_state here, rather than calling MPI_Attr_get? Is this just a symptom of the test case being reduced, and the original code attempts to access a different attribute on that communicator? I'd like to understand the original use case better, though, if you don't mind.
+}
participants (1)
-
Fab Tillier