1
1

9 Коммитов

Автор SHA1 Сообщение Дата
Nathan Hjelm
9cd955badf opal: fix multiple bugs in MCA and opal
This commit fixes the following bugs:

 - opal_output_finalize did not properly set internal state. This
   caused problems when calling the sequence opal_output_init (),
   opal_output_finalize (), opal_output_init ().

 - opal_info support called mca_base_open () but never called the
   matching mca_base_close (). mca_base_open () and mca_base_close ()
   have been updated to use a open count instead of an open flag to
   allow mca_base_open to be called through multiple paths (as may be
   the case when MPI_T is in use).

 - orte_info support did not register opal variables. This can cause
   orte-info to not return opal variables.

 - opal_info, orte_info, and ompi_info support have been updated to
   use a register count.

 - When opening the dl framework the reference count was added to
   ensure the framework stuck around. The framework being closed
   prematurely was a bug in the MCA base that has since been
   corrected. The increment (and associated decrement) have been
   removed.

 - dl/dlopen did not set the value of
   mca_dl_dlopen_component.filename_suffixes_mca_storage on each call
   to register. Instead the value was set in the component
   structure. This caused the value to be lost when re-loading the
   component. Fixed by setting the default value in register.

 - Reset shmem framework state on close to avoid returning a stale
   component after reloading opal/shmem.

 - MCA base parameters were not properly deregistered when the MCA
   base was closed.

This commit may fix #374.

Signed-off-by: Nathan Hjelm <hjelmn@lanl.gov>
2015-04-07 19:13:20 -06:00
Jeff Squyres
65a0e041ac dl: need to use LIBADD, not LIBS
When we use LIBADD for static libraries, the dependent libraries get
propagated properly.  For example, the dl/dlopen component will almost
certainly require the -ldl library; when using LIBS, that doesn't get
propagated elsewhere in the tree, but when using LIBADD, it does
(e.g., when linking opal_wrapper_compiler).
2015-03-12 15:01:14 -07:00
Jeff Squyres
8fef4e865f dl dlopen: fix use-after-free
Re-structure the loop looking for duplicates a little so that we only
have a single free of the string that happens regardless of whether we
found a duplicate or not.

This was Coverity CID 1288090
2015-03-10 07:43:20 -07:00
Jeff Squyres
3efb5f56ae dl dlopen: ensure dirs is not NULL
opal_argv_split() may have returned NULL.

This was Coverity CID 1288088
2015-03-10 07:43:20 -07:00
Jeff Squyres
86968dcdda dl dlopen: fix resource leak
closedir() was one block higher than it should have been.

This was Coverity CID 1288087.
2015-03-10 07:43:20 -07:00
Jeff Squyres
546ad3f060 dl dlopen: free resources upon error
Ensure to take the right path out upon errors (that will free any
pending resources).

This was Coverity CID 1288086
2015-03-10 07:43:19 -07:00
Jeff Squyres
39364d315c libltdl: dl component based on libltdl
Works on any system that libltdl supports and has ltdl.h and libltdl
available.
2015-03-09 08:16:55 -07:00
Jeff Squyres
7d340c0c26 dlopen: simple dl component based on POSIX dlopen
Works on systems with dlopen (e.g., Linux and OS X).  It requires
dlfcn.h and libdl, which many systems have installed by default.
2015-03-09 08:16:55 -07:00
Jeff Squyres
e81c070ef0 dl framework: new dynamic loader framework
Embedding libltdl without the use of Libtool bootstrapping has
proven... difficult.  Instead, create a new simple "dl" framework.  It
only provides 4 functions:

- open a DSO (very similar to lt_dlopenadvise())
- lookup a symbol in a previously-opened DSO (very similar to lt_dlsym())
- close a previously-opened DSO (very similar to lt_dlclose())
- iterate over all files in a directory (very similar to ld_dlforeachfile())

There will be follow-on commits with a simple dlopen-based component
(nowhere near as complete/functional as libltdl, but good enough for
Linux and OS X), and a libltdl-based component for all other
platforms.

The intent is that the dlopen-based component can be built by default
in almost all cases.  But if libltdl is available, that component will
be built.  End result: we still get DSO-based functionality by default
in (almost?) all cases.  Without embedding libltdl.  Which is what we
want.
2015-03-09 08:16:55 -07:00