Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

I don't recommend our solution as a general approach - we moved the object instance to the framework base so it never goes out of memory. Regardless, it seems to me that proper cleanup is the better solution, although it means work. I've asked that it be added to next week's telecon agenda so

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

vote for solution #1. Doesn't change current behavior. Doesn't open the >> door to becoming dependent on availability of >> ctor/dtor feature in future toolchains. >> >> Howard >> >> >> -Original Message- >> From: devel [mailto:devel-boun..

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

pen >> the door to becoming dependent on availability of >> ctor/dtor feature in future toolchains. >> >> Howard >> >> >> -----Original Message- >> From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Nathan Hjelm >> Sent: Wednesday, Jul

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

> > It would make sense, though I guess I always thought that was part of what > happened in OBJ_CLASS_INSTANCE - guess I was wrong. My thinking was that > DEREGISTER would be the counter to INSTANCE, and I do want to keep this > from getting even more clunky - so maybe renaming INSTANCE to be

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

On Jul 18, 2014, at 8:25 AM, Gilles Gouaillardet wrote: > +1 for the overall idea ! > > On Fri, Jul 18, 2014 at 10:17 PM, Ralph Castain wrote: >> * add an OBJ_CLASS_DEREGISTER and require that all instantiations be matched >> by deregister

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

+1 for the overall idea ! On Fri, Jul 18, 2014 at 10:17 PM, Ralph Castain wrote: > > * add an OBJ_CLASS_DEREGISTER and require that all instantiations be > matched by deregister at close of the framework/component that instanced > it. Of course, that requires that we protect

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

I vote for solution #1. Doesn't change current behavior. Doesn't open the >> door to becoming dependent on availability of >> ctor/dtor feature in future toolchains. >> >> Howard >> >> >> -Original Message- >> From: devel [mailto:devel-boun

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

r to becoming dependent on availability of > ctor/dtor feature in future toolchains. > > Howard > > > -Original Message- > From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Nathan Hjelm > Sent: Wednesday, July 16, 2014 9:08 AM > To: Open MPI Developers > Subject: Re:

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

evel [mailto:devel-boun...@open-mpi.org] On Behalf Of Nathan Hjelm > Sent: Wednesday, July 16, 2014 9:08 AM > To: Open MPI Developers > Subject: Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function > to opal > > On Wed, Jul 16, 2014 at 07:59:14AM -0700, Ralph Castain wrote

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

On Thu, Jul 17, 2014 at 5:55 PM, George Bosilca wrote: > Are these also called for shared libraries? > George. > If you are asking specifically about Solaris w/ the vendor compilers, then apparently Yes: -bash-3.00$ cat test.c #include int X = 0;

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

Are these also called for shared libraries? George. On Wed, Jul 16, 2014 at 3:36 PM, Paul Hargrove wrote: > > On Wed, Jul 16, 2014 at 7:36 AM, Nathan Hjelm wrote: > >> Correction. xlc does support the destructor function attribute. The odd >> one out

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

On Wed, Jul 16, 2014 at 7:36 AM, Nathan Hjelm wrote: > Correction. xlc does support the destructor function attribute. The odd > one out is PGI. > Are the Solaris Studio compilers still of interest to the Open MPI community? If so, I've confirmed support using the following

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

M To: Open MPI Developers Subject: Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal I discussed this over IM with Nathan to try and get a better understanding of the options. Basically, we have two approaches available to us: 1. my solution resolves the segv problem and

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

: Wednesday, July 16, 2014 9:08 AM To: Open MPI Developers Subject: Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal On Wed, Jul 16, 2014 at 07:59:14AM -0700, Ralph Castain wrote: > I discussed this over IM with Nathan to try and get a better understanding of > the o

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

On Wed, Jul 16, 2014 at 07:59:14AM -0700, Ralph Castain wrote: > I discussed this over IM with Nathan to try and get a better understanding of > the options. Basically, we have two approaches available to us: > > 1. my solution resolves the segv problem and eliminates leaks so long as the >

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

I discussed this over IM with Nathan to try and get a better understanding of the options. Basically, we have two approaches available to us: 1. my solution resolves the segv problem and eliminates leaks so long as the user calls MPI_Init/Finalize after calling the MPI_T init/finalize

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

On Wed, Jul 16, 2014 at 08:26:44AM -0600, Nathan Hjelm wrote: > A number of issues have been raised as part of this discussion. Here is > what I have seen so far: > > - contructor/destructor order not garaunteed: From an opal perspective >this should not be a problem. Most components are

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

Forgot to attach the patch. -Nathan diff --git a/opal/runtime/opal_finalize.c b/opal/runtime/opal_finalize.c index 318eba7..22b2e58 100644 --- a/opal/runtime/opal_finalize.c +++ b/opal/runtime/opal_finalize.c @@ -1,3 +1,4 @@ +/* -*- Mode: C; c-basic-offset:4 ; indent-tabs-mode:nil -*- */ /* *

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

A number of issues have been raised as part of this discussion. Here is what I have seen so far: - contructor/destructor order not garaunteed: From an opal perspective this should not be a problem. Most components are unloaded by opal_finalize () not opal_finalize_util (). So opal

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

Ralph and all, my understanding is that opal_finalize_util agressively tries to free memory that would be still allocated otherwise. an other way of saying "make valgrind happy" is "fully automake memory leak detection" (Joost pointed to the -fsanitize=leak feature of gcc 4.9 in

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

I've attached a solution that blocks the segfault without requiring any gyrations. Can someone explain why this isn't adequate?Alternate solution was to simply decrement opal_util_initialized in MPI_T_finalize rather than calling finalize itself. Either way resolves the problem in a very simple

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

On Tue, Jul 15, 2014 at 5:48 PM, George Bosilca wrote: > - Except for reinit, Open MPI works without it! If we provide such a > capability it will be more a convenience capability to keep valgrind happy, > than a necessity A valgrid suppression file seems like the most

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

I'm unsure where Intel's compilers sit on that list. When you say it works except for reinit, are you saying that the only issue here is that MPI_T_Finalize is calling opal_finalize_util solely because of the valgrind cleanup? And if it didn't do that, we would leak but would otherwise be just

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

Enforcing the portability of this sounds like a huge [almost impossible] mess, without a clean portable solution (more about this below). However, few things should be considered: - Except for reinit, Open MPI works without it! If we provide such a capability it will be more a convenience

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

I wonder if we aren't using a howitzer to swat a gnat. It seems to me that this is loaded with potential problems, as Paul describes, and I shudder to think of how hard this is going to be when we consider all the compiler/environment combinations we support and the range of libraries our

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

The priority appears to have been added in gcc 4.3. You'll note it is not described in https://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Function-Attributes.html I also don't think the presence of the priority argument fixes anything... An OpenMPI code author cannot change the "priority" of a ctor or

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

According to http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html *"constructor * * destructor * * constructor (*priority*)** destructor (priority)**The constructor attribute causes the function to be called automatically before execution enters main (). Similarly, the destructor attribute

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

On Tue, Jul 15, 2014 at 12:49 PM, Pritchard, Howard r wrote: > I don't think there's anything wrong with using ctor/dtors in shared > libraries, > but one does need to make sure that in these functions there's no > assumptions > about ordering of them wrt to other ctors/dtors.

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

-Original Message- From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of George Bosilca Sent: Tuesday, July 15, 2014 12:45 PM To: Open MPI Developers; Hjelm, Nathan Thomas Subject: Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal I withdraw my comment

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

I withdraw my comment on this, it turns out I “misspoke” (or in other words I was wrong about the class cleanup). The base class structures are stored as objects in the corresponding shared library memory region, and these regions become unavailable once a shared library is unloaded. As a

Re: [OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

Nathan, Fixing the classes to correctly tear down everything was a two lines patch. However, this doesn’t fix the bigger issue, which is related to the fact that not all frameworks are correctly teared down, and when they are they leave behind char* parameters not set to NULL, and that the

[OMPI devel] RFC: Add an __attribute__((destructor)) function to opal

What: Add a library destructor function to OPAL. The new function would take care of cleaning up some of OPAL's state (closing frameworks, shutting down MCA, etc). Why: OPAL can not currently be re-initialized. There are numerous problems throughout the project that will make it difficult (but