1
1
openmpi/opal/mca
Jeff Squyres fb2e543a57 Refs trac:3275.
We ran into a case where the OMPI SVN trunk grew a new acceptable MCA
parameter value, but this new value was not accepted on the v1.6
branch (hwloc_base_mem_bind_failure_action -- on the trunk it accepts
the value "silent", but on the older v1.6 branch, it doesn't).  If you
set "hwloc_base_mem_bind_failure_action=silent" in the default MCA
params file and then accidentally ran with the v1.6 branch, every OMPI
executable (including ompi_info) just failed because hwloc_base_open()
would say "hey, 'silent' is not a valid value for
hwloc_base_mem_bind_failure_action!".  Kaboom.

The only problem is that it didn't give you any indication of where
this value was being set.  Quite maddening, from a user perspective.

So we changed the ompi_info handles this case.  If any framework open
function return OMPI_ERR_BAD_PARAM (either because its base MCA params
got a bad value or because one of its component register/open
functions return OMPI_ERR_BAD_PARAM), ompi_info will stop, print out
a warning that it received and error, and then dump out the parameters
that it has received so far in the framework that had a problem.

At a minimum, this will show the user the MCA param that had an error
(it's usually the last one), and ''where it was set from'' (so that
they can go fix it).  

We updated ompi_info to check for O???_ERR_BAD_PARAM from each from
the framework opens.  Also updated the doxygen docs in mca.h for this
O???_BAD_PARAM behavior.  And we noticed that mca.h had MCA_SUCCESS
and MCA_ERR_??? codes.  Why?  I think we used them in exactly one
place in the code base (mca_base_components_open.c).  So we deleted
those and just used the normal OPAL_* codes instead.

While we were doing this, we also cleaned up a little memory
management during ompi_info/orte-info/opal-info finalization.
Valgrind still reports a truckload of memory still in use at ompi_info
termination, but they mostly look to be components not freeing
memory/resources properly (and outside the scope of this fix).

This commit was SVN r27306.

The following Trac tickets were found above:
  Ticket 3275 --> https://svn.open-mpi.org/trac/ompi/ticket/3275
2012-09-11 20:47:24 +00:00
..
backtrace Some platforms don't have <execinfo.h>, even if they have backtrace() 2011-07-10 11:14:19 +00:00
base Refs trac:3275. 2012-09-11 20:47:24 +00:00
compress Sorry for mid-day commit, but I had promised on the call to do this upon my return. 2012-04-06 14:23:13 +00:00
crs Sorry for mid-day commit, but I had promised on the call to do this upon my return. 2012-04-06 14:23:13 +00:00
event Sigh - add a continuation character so we don't lose required files 2012-08-11 16:19:29 +00:00
hwloc Refs trac:3275. 2012-09-11 20:47:24 +00:00
if Plug memory leak 2011-02-14 19:51:33 +00:00
installdirs fix several typecasts 2012-08-07 10:41:53 +00:00
memchecker Abort configure if --enable-memchecker was specified, but then no 2012-09-07 16:08:43 +00:00
memcpy Fix mistake that came in via the ompi-agen tree in r23764. The mistake wasn't part of the core autogen upgrade; it was an additional 'bonus' cleanup. Oops. The mistake will always create a set of directories under installdir, even if you do not --with-devel-headers. The set of directories will be empty, but still -- they should not be there at all. This commit fixes that -- the directories are not created at all if you do not --with-devel-headers 2010-09-24 22:53:28 +00:00
memory revert previous commit 2012-03-29 14:07:13 +00:00
pstat Gah! r25545 acidentally included ''waaaay'' more stuff than it was 2011-11-29 23:24:52 +00:00
shmem Getting out of bed this morning was a bad idea... Reverting the sm update once more because it breaks direct launch. Will address this issue and commit the update once it has all been tested. Sorry everyone! 2012-08-10 22:20:38 +00:00
timer Need to make sure that only the winning component sets the include file. 2012-02-20 16:45:54 +00:00
Makefile.am Update the copyright notices for IU and UTK. 2005-11-05 19:57:48 +00:00
mca.h Refs trac:3275. 2012-09-11 20:47:24 +00:00