Patrick, I'm afraid there is no simple way to check this. The main reason being that OMPI use handles for MPI objects, and these handles are not tracked by the library, they are supposed to be provided by the user for each call. In your case, as you already called MPI_Type_free on the datatype, you cannot produce a valid handle.
There might be a trick. If the datatype is manipulated with any Fortran MPI functions, then we convert the handle (which in fact is a pointer) to an index into a pointer array structure. Thus, the index will remain used, and can therefore be used to convert back into a valid datatype pointer, until OMPI completely releases the datatype. Look into the ompi_datatype_f_to_c_table table to see the datatypes that exist and get their pointers, and then use these pointers as arguments to ompi_datatype_dump() to see if any of these existing datatypes are the ones you define. George. On Thu, Dec 3, 2020 at 4:44 PM Patrick Bégou via users < users@lists.open-mpi.org> wrote: > Hi, > > I'm trying to solve a memory leak since my new implementation of > communications based on MPI_AllToAllW and MPI_type_Create_SubArray calls. > Arrays of SubArray types are created/destroyed at each time step and used > for communications. > > On my laptop the code runs fine (running for 15000 temporal itérations on > 32 processes with oversubscription) but on our cluster memory used by the > code increase until the OOMkiller stop the job. On the cluster we use IB > QDR for communications. > > Same Gcc/Gfortran 7.3 (built from sources), same sources of OpenMPI (3.1 > or 4.0.5 tested), same sources of the fortran code on the laptop and on the > cluster. > > Using Gcc/Gfortran 4.8 and OpenMPI 1.7.3 on the cluster do not show the > problem (resident memory do not increase and we ran 100000 temporal > iterations) > > MPI_type_free manual says that it "*Marks the datatype object associated > with datatype for deallocation*". But how can I check that the > deallocation is really done ? > > Thanks for ant suggestions. > > Patrick >
