[mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn

[Fab Tillier]

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 <jedbrown at mcs.anl.gov>
>Signed-off-by: Satish Balay <balay at mcs.anl.gov>
>---
>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.

>+}