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 we
27;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...@open-mpi.org] On Be
oor 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:0
>
> 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 REGI
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 at close of the framework/component that instanced i
+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 the class system agai
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...@open-mpi
ity 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: [OMPI devel] RFC: Add an __
l-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:
>
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;
__attribute__((__constructor__)) void hello(v
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 is PGI.
>>
>
> Are the Solaris Studio c
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 5-line test on a
Sola
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
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:
> I discussed this over IM with Nathan to try and get a better understanding of
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
> user
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 functions.
That sounds right. I don't know if this would still be required with the
destructor, but we could also:
* 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 the
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 unlo
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 -*- */
/*
*
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 component
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
http://www.open
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 man
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 appropriate tool for that
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
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 capabilit
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 variou
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
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 c
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.
>
The ELF specific
able.
Howard
-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 comm
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 result
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 fram
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 no
33 matches
Mail list logo