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
On both 1.8 and trunk (as Ralph mentioned in meeting) we are seeing three tests
fail.
http://mtt.open-mpi.org/index.php?do_redir=2205
Ibm/onesided/win_allocate_shared
Ibm/onesided/win_allocated_shared_mpifh
Ibm/onesided/win_allocated_shared_usempi
Is there a ticket that covers these failures?
T
Rolf,
From the man page of MPI_Win_allocate_shared
It is the user's responsibility to ensure that the communicator comm represents
a group of processes that can create a shared memory segment that can be
accessed by all processes in the group
And from the mtt logs, you are running 4 tasks on 2
Sounds like a good plan. Thanks for looking into this Gilles!
Regards,
Rolf
From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Gilles GOUAILLARDET
Sent: Wednesday, July 16, 2014 9:53 AM
To: Open MPI Developers
Subject: Re: [OMPI devel] Onesided failures
Rolf,
From the man page of MPI_
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
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 -*- */
/*
*
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
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
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.
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
HI Folks,
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...@open-mpi.org] On Behalf Of Nathan Hjelm
Sent: Wednesda
On Jul 15, 2014, at 2:03 PM, Mike Dubman wrote:
> these are two separate issues:
>
> 1. -x var=val (or -mca opal_base_envlist var=val) will work in the same way
> opal_base_envlist does the same as "-x" and can be used in the very same
> fashion as -x
>
> 2. When list of vars is passed with he
Nobody was "against" retaining it. The issue is that "-x" isn't an MCA
parameter, nor does it get translated to one under the covers. So the problem
was one of how to insert it into the typical MCA param precedence chain.
If we don't try to do that, but instead simply error out if both -x and th
What about providing garbage collection for both POSIX and MPI threads? This
problem hints at several underlying layers of "programming faults".
-Original Message-
From: devel [mailto:devel-boun...@open-mpi.org] On Behalf Of Ralph Castain
Sent: Wednesday, July 16, 2014 8:59 AM
To: Open MPI
On Jul 16, 2014, at 11:31 AM, Ralph Castain wrote:
> Nobody was "against" retaining it. The issue is that "-x" isn't an MCA
> parameter, nor does it get translated to one under the covers. So the problem
> was one of how to insert it into the typical MCA param precedence chain.
I understand th
Don't look at me - I didn't care to begin with as I never use -x and won't be
using this param! :-)
My point was only that having both is clunky and leads to potential conflict.
No good solution, so
On Jul 16, 2014, at 9:57 AM, Dave Goodell (dgoodell) wrote:
> On Jul 16, 2014, at 11:31 AM,
we have a strong use-case for list of env variables passed as mca params.(it
was presented and discussed in the past).
we can rename opal_base_envlist as "-mca x var=val" for consistency.
also, "-x" param now is just an alias for "-mca opal_base_envlist var=val"
- so, we can keep it (w/o deprecati
Dave,
Your example will error out. If someone tries to set envars with both
mechanism, the job fails. The decision to do so was also made at the Dev
meeting and is so that we don't have to do this kind of checking.
Josh
On Wed, Jul 16, 2014 at 12:22 PM, Dave Goodell (dgoodell) <
dgood...@cisco.
On Jul 16, 2014, at 12:27 PM, Joshua Ladd wrote:
> Dave,
>
> Your example will error out. If someone tries to set envars with both
> mechanism, the job fails. The decision to do so was also made at the Dev
> meeting and is so that we don't have to do this kind of checking.
Hmm, indeed it doe
On Jul 16, 2014, at 12:15 PM, Mike Dubman wrote:
> we have a strong use-case for list of env variables passed as mca params.(it
> was presented and discussed in the past).
I'm not disputing your use case for "mca_base_env_list". I'm only lamenting
the crapification of our mpirun user interfac
On Jul 16, 2014, at 11:34 AM, Dave Goodell (dgoodell)
wrote:
> On Jul 16, 2014, at 12:15 PM, Mike Dubman wrote:
>
>> we have a strong use-case for list of env variables passed as mca params.(it
>> was presented and discussed in the past).
>
> I'm not disputing your use case for "mca_base_en
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
Ralph warned me that no matter what decision we made, someone would
probably violently object. So, with that in mind, let me put my diplomat
hat on...
Dave, I'm sorry you view this as a "crapification" of your mpirun user
interface. Your lament is duly noted and we are happy to work with you to
co
On Jul 16, 2014, at 3:08 PM, Joshua Ladd wrote:
> Ralph warned me that no matter what decision we made, someone would probably
> violently object. So, with that in mind, let me put my diplomat hat on...
FWIW, I don't think my objections here have been "violent".
> Dave, I'm sorry you view this
*An enhancement to permit some form of delimiter escaping would probably
still be nice, but is low priority.*
[Josh] Not a problem, Dave. We will do this.
On Wed, Jul 16, 2014 at 4:32 PM, Dave Goodell (dgoodell) wrote:
> On Jul 16, 2014, at 3:08 PM, Joshua Ladd wrote:
>
> > Ralph warned me tha
25 matches
Mail list logo
