Hello,
> Author: brbarret
> Date: 2007-07-18 16:23:45 EDT (Wed, 18 Jul 2007)
> New Revision: 15492
> URL: https://svn.open-mpi.org/trac/ompi/changeset/15492
>
> Log:
> add ability to have thread-specific data on windows, pthreads, solaris
> threads,
> and non-threaded builds
>
> +int
> +opal_tsd_k
Jeff Squyres wrote:
Background: Pasha added a call in the openib BTL finalize function
that will only succeed if all registered memory has been released
(ibv_dealloc_pd()). Since the test app didn't call MPI_FREE_MEM,
there was some memory that was still registered, and therefore the
call
Thanks!
Ralph got it this morning in https://svn.open-mpi.org/trac/ompi/
changeset/15501.
On Jul 19, 2007, at 5:34 AM, Bert Wesarg wrote:
Hello,
Author: brbarret
Date: 2007-07-18 16:23:45 EDT (Wed, 18 Jul 2007)
New Revision: 15492
URL: https://svn.open-mpi.org/trac/ompi/changeset/15492
L
On Wed, Jul 18, 2007 at 09:08:38PM +0300, Gleb Natapov wrote:
> On Wed, Jul 18, 2007 at 09:08:47AM -0600, Ralph H Castain wrote:
> > But this will lockup:
> >
> > pn1180961:~/openmpi/trunk rhc$ mpirun -n 1 -host pn1180961 printenv | grep
> > LD
> >
> > The reason is that the hostname in this last
Interesting. Apparently, it is getting a NULL back when it tries to access
the LD_LIBRARY_PATH in your environment. Here is the code involved:
newenv = opal_os_path( false, prefix_dir, lib_base, NULL );
oldenv = getenv("LD_LIBRARY_PATH");
if (NULL != oldenv) {
char* temp;
On Thu, Jul 19, 2007 at 08:07:51AM -0600, Ralph H Castain wrote:
> Interesting. Apparently, it is getting a NULL back when it tries to access
> the LD_LIBRARY_PATH in your environment. Here is the code involved:
>
> newenv = opal_os_path( false, prefix_dir, lib_base, NULL );
> oldenv = g
Sigh. Thanks. Should probably have tested that code ;). And the
solaris code. and the windows code.
Brian
On Jul 19, 2007, at 7:37 AM, Jeff Squyres wrote:
Thanks!
Ralph got it this morning in https://svn.open-mpi.org/trac/ompi/
changeset/15501.
On Jul 19, 2007, at 5:34 AM, Bert Wesarg
It wasn't a bug. There is a bunch of code there just to make sure
PATH and LD_LIBRARY_PATH are set correctly.
Yesterday we discovered that even if you force the --prefix in a
similar execution environment the LD_LIBRARY_PATH doesn't get set.
However, using localhost always solve the problem
But it *does* provide an LD_LIBRARY_PATH that is pointing to your openmpi
installation - it says it did it right here in your debug output:
>>> [elfit1:14752] pls:rsh: reset LD_LIBRARY_PATH: /home/glebn/openmpi/lib
I suspect that the problem isn't in the launcher, but rather in the iof
again. Why
The problem occurs in the following situation. In the rsh PLS the
number of daemons that have to be spawned is set to zero (as mpirun
act now as a daemon). Therefore, the PLS rsh don't do anything except
sending the launch order to the daemons. Then the remaining of the
work is done in the
The second execution (the one that you make reference to) is the one
that works fine. The failing one is the first one, where
LD_LIBRARY_PATH is not provided. As Gleb indicate using localhost
make the problem vanish.
george.
On Jul 19, 2007, at 10:57 AM, Ralph H Castain wrote:
But it *d
You are correct - I misread the note. My bad.
I'll look at how we might ensure the LD_LIBRARY_PATH shows up correctly -
shouldn't be a big deal.
On 7/19/07 9:12 AM, "George Bosilca" wrote:
> The second execution (the one that you make reference to) is the one
> that works fine. The failing one
Talked with Brian and we have identified the problem and a fix - will come
in later today.
Thanks
Ralph
On 7/19/07 9:24 AM, "Ralph H Castain" wrote:
> You are correct - I misread the note. My bad.
>
> I'll look at how we might ensure the LD_LIBRARY_PATH shows up correctly -
> shouldn't be a
I fixed the specific problem of setting the LD_LIBRARY_PATH (and PATH,
though that wasn't mentioned) for the case of procs spawned locally by
mpirun - see r15516. Please confirm that the problem is gone and/or let me
know if it persists for you.
The issue of name resolution is a more general probl
I have a *BIG DOUBT* about this approach. The problem will lead to
some really strange situations, as we change the LD_LIBRARY_PATH of a
process in the middle of the run. As a result the place from where we
load dynamic libraries before and after this call will potentially
became different.
I believe you may have misunderstood the change. I don't change anyone's
path in the middle of the run. I only alter the environment that the odls
uses to launch the child processes, and that gets applied to the child at
execve time. Mpirun's environment remains unchanged.
So I'm not sure I unders
Sorry, you're right. You store them in the launch environment, which
will be used later by the ODLS to setup the environment for the child.
george.
On Jul 19, 2007, at 3:46 PM, Ralph H Castain wrote:
I believe you may have misunderstood the change. I don't change
anyone's
path in the midd
This change has finally been merged into the trunk as r15517. It will
unfortunately require an autogen (sorry).
Please let me know if you encounter any problems. As noted in the commit, I
tried to catch all the places that required change, but cannot guarantee
that I got all of them.
Thanks
Ralph
Have any of you ever consider asking OpenMPI being included here, as
it is an open source project?
http://scan.coverity.com/index.html
From many sources (mainly related to Python), it seems the results are
impressive.
Regards,
--
Lisandro Dalcín
---
Centro Internacional de Método
Yes, we have (someone else brought it to our attention a few months
ago). :-)
Hopefully we'll have more news on this front in the not-distant future.
On Jul 19, 2007, at 9:07 PM, Lisandro Dalcin wrote:
Have any of you ever consider asking OpenMPI being included here, as
it is an open sourc
20 matches
Mail list logo
