Committed as r29922 with:
Changes from V2:
* use orte_rml_oob_ft_event() instead of referencing through the modules
* properly protect variable (thanks to --enable-picky)
Adrian
On Mon, Dec 09, 2013 at 03:39:11PM -0600, Josh Hursey wrote:
> With the modification that Ralph mentio
Adrian --
Can you add yourself to the AUTHORS and .mailmap files on the trunk? This
helps us keep the git and hg mirrors proper.
On Dec 16, 2013, at 10:37 AM, Adrian Reber wrote:
> Committed as r29922 with:
>
> Changes from V2:
> * use orte_rml_oob_ft_event() instead of referencing through
FYI: If you'd like your proper name and email address to appear on the Open MPI
github mirror, please edit your entry in the SVN trunk/.mailmap file.
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
I took a look at the stacktraces last week and could not identify where the bug
is. I will dig deeper this week and see if I can come up with the correct fix.
-Nathan
On Mon, Dec 09, 2013 at 03:17:36PM +0200, Mike Dubman wrote:
>Nathan,
>Could you please comment on the Igor`s observations
It might be worthwhile to run this through valgrind and see if something is
being freed incorrectly...?
On Dec 16, 2013, at 12:11 PM, Nathan Hjelm wrote:
> I took a look at the stacktraces last week and could not identify where the
> bug
> is. I will dig deeper this week and see if I can come
After speaking with Igor Ivanov about this this morning, he summarized his
findings as follows:
1. Valgrind comes up clean.
2. The issue is not reproduced with a static build.
3. A bisection study reveals that problems first appear after commit:
https://svn.open-mpi.org/trac/ompi/changeset/28800
That is one possibility. The mca_base_var_t in question look like junk to me.
Should be
impossible since variables are only destructed in mca_base_var_finalize. My
guess is
that something is stomping on the variable memory.
-Nathan
On Mon, Dec 16, 2013 at 05:14:22PM +, Jeff Squyres (jsquyre
On Mon, Dec 16, 2013 at 05:21:05PM +, Joshua Ladd wrote:
> After speaking with Igor Ivanov about this this morning, he summarized his
> findings as follows:
>
> 1. Valgrind comes up clean.
Thats good to hear but unfortunate since this seems really like a
stomping-on-memory problem.
> 2. The
What: Move the initialization of the openib btl's free lists from
btl_init to btl_add_procs.
Why: We are planning to always initialize the btls to support
oshmem. Since the openib btl always sets up its free lists, allocates
fragments, starts the async event thread, etc as part of btl_init we
will
Sorry for not being clear; that's exactly what I was saying.
Brian
On 12/14/13 8:49 AM, "Mike Dubman"
mailto:mi...@dev.mellanox.co.il>> wrote:
ohh.. i see.
thanks for clarification.
This is exactly how it is treated in our internal repo based on 1.7 and we will
push it into trunk soon.
On Sa
10 matches
Mail list logo