openmpi/ompi/mca/mpool/base/help-mpool-base.txt

# -*- text -*-
#
# Copyright (c) 2007-2009 Cisco Systems, Inc.  All rights reserved.
# $COPYRIGHT$
# 
# Additional copyrights may follow
# 
# $HEADER$
#
[all mem leaks]
The following memory locations were allocated via MPI_ALLOC_MEM but
not freed via MPI_FREE_MEM before invoking MPI_FINALIZE:

Process ID: %s
Hostname:   %s
PID:        %d

%s
#
[some mem leaks]
The following memory locations were allocated via MPI_ALLOC_MEM but
not freed via MPI_FREE_MEM before invoking MPI_FINALIZE:

Process ID: %s
Hostname:   %s
PID:        %d

%s

%d additional leak%s recorded but %s not displayed here.  Set the MCA
parameter mpi_show_mpi_alloc_mem_leaks to a larger number to see that
many leaks, or set it to a negative number to see all leaks.
#
[leave pinned failed]
A process attempted to use the "leave pinned" MPI feature, but no
memory registration hooks were found on the system at run time.  This
may be the result of running on a system that does not support memory
hooks or having some other software subvert Open MPI's use of the
memory hooks.  You can disable Open MPI's use of memory hooks by
setting both the mpi_leave_pinned and mpi_leave_pinned_pipeline MCA
parameters to 0.

Open MPI will disable any transports that are attempting to use the
leave pinned functionality; your job may still run, but may fall back
to a slower network transport (such as TCP).

  Mpool name: %s
  Process:    %s
  Local host: %s
#
[cannot deregister in-use memory]
Open MPI intercepted a call to free memory that is still being used by
an ongoing MPI communication.  This usually reflects an error in the
MPI application; it may signify memory corruption.  Open MPI will now
abort your job.

  Mpool name:     %s
  Local host:     %s
  Buffer address: %p
  Buffer size:    %lu
Introduce a new debugging MCA parameter: mpi_show_mpi_alloc_mem_leaks When activated, MPI_FINALIZE displays a list of memory allocations from MPI_ALLOC_MEM that were not freed by MPI_FREE_MEM (in each MPI process). * If set to a positive integer, display only that many leaks. * If set to a negative integer, display all leaks. * If set to 0, do not show any leaks. This commit was SVN r15736. 2007-08-02 01:33:25 +04:00			`# -- text --`
			`#`
Per http://www.open-mpi.org/community/lists/announce/2009/03/0029.php and https://svn.open-mpi.org/trac/ompi/ticket/1853, mallopt() hints do not always work -- it is possible for memory to be returned to the OS and therefore OMPI's registration cache becomes invalid. This commit removes all use of mallopt() and uses a different way to integrate ptmalloc2 than we have done in the past. In particular, we use almost exactly the same technique as MX: * Remove all uses of mallopt, to include the opal/memory mallopt component. * Name-shift all of OMPI's internal ptmalloc2 public symbols (e.g., malloc -> opal_memory_ptmalloc2_malloc). * At run-time, use the existing glibc allocator malloc hook function pointers to fully hijack the glibc allocator with our own name-shifted ptmalloc2. * Make the decision whether to hijack the glibc allocator ''at run time'' (vs. at link time, as previous ptmalloc2 integration attempts have done). Look at the OMPI_MCA_mpi_leave_pinned and OMPI_MCA_mpi_leave_pinned_pipeline environment variables and the existence of /sys/class/infiniband to determine if we should install the hooks or not. * As an added bonus, we can now tell if libopen-pal is linked statically or dynamically, and if we're linked statically, we assume that munmap intercept support doesn't work. See the opal/mca/memory/ptmalloc2/README-open-mpi.txt file for all the gory details about the implementation. Fixes trac:1853. This commit was SVN r20921. The following Trac tickets were found above: Ticket 1853 --> https://svn.open-mpi.org/trac/ompi/ticket/1853 2009-04-01 21:52:16 +04:00			`# Copyright (c) 2007-2009 Cisco Systems, Inc. All rights reserved.`
Introduce a new debugging MCA parameter: mpi_show_mpi_alloc_mem_leaks When activated, MPI_FINALIZE displays a list of memory allocations from MPI_ALLOC_MEM that were not freed by MPI_FREE_MEM (in each MPI process). * If set to a positive integer, display only that many leaks. * If set to a negative integer, display all leaks. * If set to 0, do not show any leaks. This commit was SVN r15736. 2007-08-02 01:33:25 +04:00			`# $COPYRIGHT$`
			`#`
			`# Additional copyrights may follow`
			`#`
			`# $HEADER$`
			`#`
			`[all mem leaks]`
			`The following memory locations were allocated via MPI_ALLOC_MEM but`
			`not freed via MPI_FREE_MEM before invoking MPI_FINALIZE:`

			`Process ID: %s`
			`Hostname: %s`
			`PID: %d`

			`%s`
			`#`
			`[some mem leaks]`
			`The following memory locations were allocated via MPI_ALLOC_MEM but`
			`not freed via MPI_FREE_MEM before invoking MPI_FINALIZE:`

			`Process ID: %s`
			`Hostname: %s`
			`PID: %d`

			`%s`

			`%d additional leak%s recorded but %s not displayed here. Set the MCA`
			`parameter mpi_show_mpi_alloc_mem_leaks to a larger number to see that`
			`many leaks, or set it to a negative number to see all leaks.`
Per http://www.open-mpi.org/community/lists/announce/2009/03/0029.php and https://svn.open-mpi.org/trac/ompi/ticket/1853, mallopt() hints do not always work -- it is possible for memory to be returned to the OS and therefore OMPI's registration cache becomes invalid. This commit removes all use of mallopt() and uses a different way to integrate ptmalloc2 than we have done in the past. In particular, we use almost exactly the same technique as MX: * Remove all uses of mallopt, to include the opal/memory mallopt component. * Name-shift all of OMPI's internal ptmalloc2 public symbols (e.g., malloc -> opal_memory_ptmalloc2_malloc). * At run-time, use the existing glibc allocator malloc hook function pointers to fully hijack the glibc allocator with our own name-shifted ptmalloc2. * Make the decision whether to hijack the glibc allocator ''at run time'' (vs. at link time, as previous ptmalloc2 integration attempts have done). Look at the OMPI_MCA_mpi_leave_pinned and OMPI_MCA_mpi_leave_pinned_pipeline environment variables and the existence of /sys/class/infiniband to determine if we should install the hooks or not. * As an added bonus, we can now tell if libopen-pal is linked statically or dynamically, and if we're linked statically, we assume that munmap intercept support doesn't work. See the opal/mca/memory/ptmalloc2/README-open-mpi.txt file for all the gory details about the implementation. Fixes trac:1853. This commit was SVN r20921. The following Trac tickets were found above: Ticket 1853 --> https://svn.open-mpi.org/trac/ompi/ticket/1853 2009-04-01 21:52:16 +04:00			`#`
- The ptmalloc2 memory manager component is now by default built as a standalone library named libopenmpi-malloc. Users wanting to use leave_pinned with ptmalloc2 will now need to link the library into their application explicitly. All other users will use the libc-provided allocator instead of Open MPI's ptmalloc2. This change may be overriden with the configure option enable-ptmalloc2-internal - The leave_pinned options will now default to using mallopt on Linux in the cases where ptmalloc2 was not linked in. mallopt will also only be available if munmap can be intercepted (the default whenever Open MPI is not compiled with --without-memory- manager. - Open MPI will now complain and refuse to use leave_pinned if no memory intercept / mallopt option is available. This commit was SVN r18654. 2008-06-14 02:32:49 +04:00			`[leave pinned failed]`
Per http://www.open-mpi.org/community/lists/announce/2009/03/0029.php and https://svn.open-mpi.org/trac/ompi/ticket/1853, mallopt() hints do not always work -- it is possible for memory to be returned to the OS and therefore OMPI's registration cache becomes invalid. This commit removes all use of mallopt() and uses a different way to integrate ptmalloc2 than we have done in the past. In particular, we use almost exactly the same technique as MX: * Remove all uses of mallopt, to include the opal/memory mallopt component. * Name-shift all of OMPI's internal ptmalloc2 public symbols (e.g., malloc -> opal_memory_ptmalloc2_malloc). * At run-time, use the existing glibc allocator malloc hook function pointers to fully hijack the glibc allocator with our own name-shifted ptmalloc2. * Make the decision whether to hijack the glibc allocator ''at run time'' (vs. at link time, as previous ptmalloc2 integration attempts have done). Look at the OMPI_MCA_mpi_leave_pinned and OMPI_MCA_mpi_leave_pinned_pipeline environment variables and the existence of /sys/class/infiniband to determine if we should install the hooks or not. * As an added bonus, we can now tell if libopen-pal is linked statically or dynamically, and if we're linked statically, we assume that munmap intercept support doesn't work. See the opal/mca/memory/ptmalloc2/README-open-mpi.txt file for all the gory details about the implementation. Fixes trac:1853. This commit was SVN r20921. The following Trac tickets were found above: Ticket 1853 --> https://svn.open-mpi.org/trac/ompi/ticket/1853 2009-04-01 21:52:16 +04:00			`A process attempted to use the "leave pinned" MPI feature, but no`
			`memory registration hooks were found on the system at run time. This`
			`may be the result of running on a system that does not support memory`
			`hooks or having some other software subvert Open MPI's use of the`
			`memory hooks. You can disable Open MPI's use of memory hooks by`
			`setting both the mpi_leave_pinned and mpi_leave_pinned_pipeline MCA`
			`parameters to 0.`

			`Open MPI will disable any transports that are attempting to use the`
			`leave pinned functionality; your job may still run, but may fall back`
			`to a slower network transport (such as TCP).`

			`Mpool name: %s`
			`Process: %s`
			`Local host: %s`
Make mpool fail-to-unregister-freed-memory errors be fatal. Try to make that routine a bit more safe, too (ensure to not call malloc and friends if from_alloc==true). This commit was SVN r20984. 2009-04-14 04:54:20 +04:00			`#`
			`[cannot deregister in-use memory]`
			`Open MPI intercepted a call to free memory that is still being used by`
			`an ongoing MPI communication. This usually reflects an error in the`
			`MPI application; it may signify memory corruption. Open MPI will now`
			`abort your job.`

			`Mpool name: %s`
			`Local host: %s`
			`Buffer address: %p`
			`Buffer size: %lu`