[hwloc-devel] Create success (hwloc r1.0a1r1450)

[MPI Team]

Creating nightly hwloc snapshot SVN tarball was a success.

Snapshot:   hwloc 1.0a1r1450
Start time: Tue Dec  8 21:01:05 EST 2009
End time:   Tue Dec  8 21:03:02 EST 2009

Your friendly daemon,
Cyrador

[OMPI devel] Open MPI v1.4 release: explanation

[Jeff Squyres]

The Open MPI Team, representing a consortium of research, academic, and 
industry partners is just about to release Open MPI version 1.4 in reaction to 
the GNU Libtool 2.2.6b security update release (see 
http://security-tracker.debian.org/tracker/CVE-2009-3736 for more details).

This mail contains a few more details than the upcoming v1.4 announcement mail.

The Open MPI v1.4 release closes a potential security vulnerability associated 
with the embedded version of GNU Libtool used in the Open MPI v1.3.x series.  
The *only* change between Open MPI v1.3.4 and Open MPI v1.4 is that we used GNU 
Libtool 2.2.6b to build Open MPI v1.4, thereby updating Open MPI's embedded 
copy of the "libltdl" library.

*** NOTE: We feel that this GNU Libtool libltdl vulnerability has
minimal/trivial impact on Open MPI, but are releasing v1.4 with
the update for the following reasons:

- It is a convenient excuse to transition the v1.3 "feature
  release" series in to the v1.4 "stable/bug fix" series.
- It serves to encourage all v1.2[.x] users to upgrade to the v1.4
  series.

Note that the GNU Libtool libltdl problem extends back quite a few versions, 
and affects multiple Open MPI versions:

 - v1.0 series: This series is ancient and no longer maintained.
 - v1.1 series: This series is ancient and no longer maintained.
 - v1.2 series: Until today, the v1.2 series was technically the
   stable release.  However, the majority of Open MPI users are
   already using the v1.3 series.  As such, there are currently no
   plans to patch the v1.2 series.
 - v1.3 series: As of today, this series has formally transitioned to
   the v1.4 series; no more releases will be made.
 - v1.4 series: First release today.

As mentioned above, v1.2[.x] users are encouraged to upgrade to the v1.4 
release.  If you cannot upgrade to v1.4 but need the security fix, please send 
a note to the Open MPI user's list to help us gauge the demand for a v1.2.10 
release.

-- 
Jeff Squyres
jsquy...@cisco.com

Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1447

[Brice Goglin]

jsquy...@osl.iu.edu wrote:
> Author: jsquyres
> Date: 2009-12-08 13:15:03 EST (Tue, 08 Dec 2009)
> New Revision: 1447
> URL: https://svn.open-mpi.org/trac/hwloc/changeset/1447
>
> Log:
> New require LT 2.2.6b
>   

By the way, isn't LT_INIT supposed to enforce the required version? We
had a bug report from somebody running libtool 1.5 (in the libpci
branch). He got obscur errors during autogen.sh, but nothing said
clearly that his libtool was too old...

Brice

Re: [OMPI devel] Crash when using MPI_REAL8

[Jeff Squyres]

...and cmr to v1.5.  ;-)

(see https://svn.open-mpi.org/trac/ompi/ticket/2133)



On Dec 8, 2009, at 12:33 PM, George Bosilca wrote:

> Rainer,
> 
> The patch looks correct. Please feel free to push it in the trunk.
> 
>  Thanks,
>george.
> 
> On Dec 7, 2009, at 11:27 , Rainer Keller wrote:
> 
>> Hello Sylvain,
>> 
>> On Friday 04 December 2009 02:27:22 pm Sylvain Jeaugey wrote:
>>> There is definetly something wrong in types.
>> Yes, the new ids for optional Fortran datatypes are wrong.
>> 
>> So, as with other Fortran types, IMHO they need to map to C types, aka the 
>> IDs 
>> should map. Therefore, we should _not_ increase the number of predefined 
>> types 
>> -- these are fixed as representable by C...
>> 
>> The below patch does just that and fixes Your testcase!
>> 
>> George, what do You think? Could You check, please?
>> 
>> Best regards,
>> Rainer
>> 
>> PS: Yes, You're perfectly right, that the number of Fortran tests (esp. with 
>> regard to optional ddt) are too low.
>> Several features of MPI (MPI-2 are not well represented in MTT).
>> -- 
>> 
>> Rainer Keller, PhD  Tel: +1 (865) 241-6293
>> Oak Ridge National Lab  Fax: +1 (865) 241-4811
>> PO Box 2008 MS 6164   Email: kel...@ornl.gov
>> Oak Ridge, TN 37831-2008AIM/Skype: rusraink
>> 
>> ___
>> devel mailing list
>> de...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel


-- 
Jeff Squyres
jsquy...@cisco.com

Re: [OMPI devel] Question about ompi_proc_t

[Pavel Shamis (Pasha)]

Both of these types (mca_pml_endpoint_t and mca_pml_base_endpoint_t) are 
meaningless, they can safely be replaced by void*. We have them clearly typed 
(but with just for the sake of understanding, so one can easily figure out what 
is supposed to be stored in this specific field. As such, we can remove one of 
them (mca_pml_base_endpoint_t) and use the other one (mca_pml_endpoint_t) 
everywhere.
  
George, thank you for clarification! For me it sound like a good idea to 
leave only one of them.

I wonder what is exactly the reason that drives your questions?
  

The question was raised during internal top-down code review.

Regards,
Pasha

  

George,
Actually My original question was correct.

In the ompi code base I found ONLY two places where we "use" the structure.
Actually we only assign values for the pointer in DR and CM PML:

ompi/mca/pml/cm/pml_cm.c:145:procs[i]->proc_pml = (struct 
mca_pml_base_endpoint_t*) endpoints[i];
ompi/mca/pml/dr/pml_dr.c:264:procs[i]->proc_pml = (struct 
mca_pml_base_endpoint_t*) endpoint;

I do not see any struct definiton/declaration mca_pml_base_endpoint_t in the 
OMPI code at all.

But I do see the "struct mca_pml_endpoint_t;" declaration in pml.h. As well, I comment 
that says: "A pointer to an mca_pml_endpoint_t is maintained on each ompi_proc_t". So it 
looks that the idea was to use use mca_pml_endpoint_t on the ompi_proc_t and not 
mca_pml_base_endpoint_t, is not it ?

Thanks !

Pasha

George Bosilca wrote:


Actually your answer is correct. The endpoint is defined down below in the PML. 
In addition, I think only the MTL and the DR PML use it, all OB1 derivative 
completely ignore it.

 george.

On Dec 7, 2009, at 08:30 , Timothy Hayes wrote:

 
  

Sorry, I think I read your question too quickly. Ignore me. :-)

2009/12/7 Timothy Hayes 
Is it not a forward definition and then defined in the PML components 
individually based on their own requirements?

2009/12/7 Pavel Shamis (Pasha) 

In the ompi_proc_t structure (ompi/proc/proc.h:54) we keep pointer to proc_pml - "struct 
mca_pml_base_endpoint_t* proc_pml" . I tired to find definition for "struct 
mca_pml_base_endpoint_t" , but I failed. Does somebody know where is it defined ?

Regards,
Pasha
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
   

 
  



  

Re: [OMPI devel] Question about ompi_proc_t

[George Bosilca]

I have a better solution ;) Implemented in r22277.

  george.

On Dec 8, 2009, at 12:17 , Jeff Squyres wrote:

> On Dec 8, 2009, at 12:05 PM, George Bosilca wrote:
> 
>> Both of these types (mca_pml_endpoint_t and mca_pml_base_endpoint_t) are 
>> meaningless, they can safely be replaced by void*. We have them clearly 
>> typed (but with just for the sake of understanding, so one can easily figure 
>> out what is supposed to be stored in this specific field. As such, we can 
>> remove one of them (mca_pml_base_endpoint_t) and use the other one 
>> (mca_pml_endpoint_t) everywhere.
> 
> It would probably be good to put this in a comment somewhere in the code 
> base.  :-)
> 
> -- 
> Jeff Squyres
> jsquy...@cisco.com
> 
> 
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel

Re: [OMPI devel] Question about ompi_proc_t

[Jeff Squyres]

On Dec 8, 2009, at 12:05 PM, George Bosilca wrote:

> Both of these types (mca_pml_endpoint_t and mca_pml_base_endpoint_t) are 
> meaningless, they can safely be replaced by void*. We have them clearly typed 
> (but with just for the sake of understanding, so one can easily figure out 
> what is supposed to be stored in this specific field. As such, we can remove 
> one of them (mca_pml_base_endpoint_t) and use the other one 
> (mca_pml_endpoint_t) everywhere.

It would probably be good to put this in a comment somewhere in the code base.  
:-)

-- 
Jeff Squyres
jsquy...@cisco.com

Re: [OMPI devel] Question about ompi_proc_t

[George Bosilca]

Pasha,

Both of these types (mca_pml_endpoint_t and mca_pml_base_endpoint_t) are 
meaningless, they can safely be replaced by void*. We have them clearly typed 
(but with just for the sake of understanding, so one can easily figure out what 
is supposed to be stored in this specific field. As such, we can remove one of 
them (mca_pml_base_endpoint_t) and use the other one (mca_pml_endpoint_t) 
everywhere.

I wonder what is exactly the reason that drives your questions?

  george.


On Dec 8, 2009, at 04:18 , Pavel Shamis (Pasha) wrote:

> George,
> Actually My original question was correct.
> 
> In the ompi code base I found ONLY two places where we "use" the structure.
> Actually we only assign values for the pointer in DR and CM PML:
> 
> ompi/mca/pml/cm/pml_cm.c:145:procs[i]->proc_pml = (struct 
> mca_pml_base_endpoint_t*) endpoints[i];
> ompi/mca/pml/dr/pml_dr.c:264:procs[i]->proc_pml = (struct 
> mca_pml_base_endpoint_t*) endpoint;
> 
> I do not see any struct definiton/declaration mca_pml_base_endpoint_t in the 
> OMPI code at all.
> 
> But I do see the "struct mca_pml_endpoint_t;" declaration in pml.h. As well, 
> I comment that says: "A pointer to an mca_pml_endpoint_t is maintained on 
> each ompi_proc_t". So it looks that the idea was to use use 
> mca_pml_endpoint_t on the ompi_proc_t and not mca_pml_base_endpoint_t, is not 
> it ?
> 
> Thanks !
> 
> Pasha
> 
> George Bosilca wrote:
>> Actually your answer is correct. The endpoint is defined down below in the 
>> PML. In addition, I think only the MTL and the DR PML use it, all OB1 
>> derivative completely ignore it.
>> 
>>  george.
>> 
>> On Dec 7, 2009, at 08:30 , Timothy Hayes wrote:
>> 
>>  
>>> Sorry, I think I read your question too quickly. Ignore me. :-)
>>> 
>>> 2009/12/7 Timothy Hayes 
>>> Is it not a forward definition and then defined in the PML components 
>>> individually based on their own requirements?
>>> 
>>> 2009/12/7 Pavel Shamis (Pasha) 
>>> 
>>> In the ompi_proc_t structure (ompi/proc/proc.h:54) we keep pointer to 
>>> proc_pml - "struct mca_pml_base_endpoint_t* proc_pml" . I tired to find 
>>> definition for "struct mca_pml_base_endpoint_t" , but I failed. Does 
>>> somebody know where is it defined ?
>>> 
>>> Regards,
>>> Pasha
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> 
>>> 
>>> 
>>> ___
>>> devel mailing list
>>> de...@open-mpi.org
>>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>
>> 
>> 
>>  
> 

Re: [OMPI devel] [patch] Verifying the message queue DLL build

[Terry Dontje]

Ashley Pittman wrote:

On Tue, 2009-12-08 at 07:39 -0500, Terry Dontje wrote:
  

Ashley Pittman wrote:


I've seen several cases now where people have functional, installed MPI
libraries yet when they've come to use padb they have discovered a build
problem with the Message Queue DLL which prevents it from working.

  
  
The cases I've seen this happen is with the Sun Studio compiler when a 
source file pulls in a header that defines an inline static function 
that uses some extern symbols but the inline static function itself is 
never used.  For some reason Sun Studio (I believe I've seen another 
compiler do this also pgi or pathscale I think) decides to make those 
extern symbols unresolved instead of just ignoring them.



That explains a couple of occurrences I've seen.  Another example is
Jeffs debug-handles branch where the code incorrectly called free
instead of mqs_free, unfortunately free is #defined to be opal_free
which then becomes an undefined symbol.

  
The current trunk and 1.5 branch should have this issue extricated from 
it.  However, this seems to always creep in every so often.  So the 
below test is greatly appreciated.  Also, have you ran this test against 
the trunk and 1.5, yet (is my belief of things are clean there correct)?



I've run it against a slightly stale version of the trunk which is as
you say clean currently.  I'm not sure where I'd get a 1.5 branch from
but if you point me to it I can test this as well.
  

You can get it from the svn branch repo:
https://svn.open-mpi.org/svn/ompi/branches/v1.5
You might as well also try 1.4 which should also be clean:
https://svn.open-mpi.org/svn/ompi/branches/v1.4

--td

Ashley,

  

Re: [hwloc-devel] Disabling X component

[Samuel Thibault]

Hello,

Ashley Pittman, le Fri 04 Dec 2009 12:08:11 +, a écrit :
> On Fri, 2009-12-04 at 13:04 +0100, Samuel Thibault wrote:
> > Ashley Pittman, le Fri 04 Dec 2009 11:06:12 +, a écrit :
> > > The debian version of -.txt (lstopo 0.9.3rc1) leaves my terminal with
> > > the colours inverted after I call it, I have to do a reset to get back
> > > to black on grey background.
> > 
> > Uh, odd. Which terminal are you using?
> 
> gnome-terminal with $TERM set to xterm.  I've not done anything special
> with this, it's just a debian unstable install.

Ok, I was always resetting to white on black :o)

I have added proper reset support, it just took me some time to realize
that just looking for "color" in terminfo wasn't enough and I had to
look for "pair".

Samuel

Re: [OMPI devel] [patch] Verifying the message queue DLL build

[Ashley Pittman]

On Tue, 2009-12-08 at 07:39 -0500, Terry Dontje wrote:
> Ashley Pittman wrote:
> > I've seen several cases now where people have functional, installed MPI
> > libraries yet when they've come to use padb they have discovered a build
> > problem with the Message Queue DLL which prevents it from working.
> >
> >   
> The cases I've seen this happen is with the Sun Studio compiler when a 
> source file pulls in a header that defines an inline static function 
> that uses some extern symbols but the inline static function itself is 
> never used.  For some reason Sun Studio (I believe I've seen another 
> compiler do this also pgi or pathscale I think) decides to make those 
> extern symbols unresolved instead of just ignoring them.

That explains a couple of occurrences I've seen.  Another example is
Jeffs debug-handles branch where the code incorrectly called free
instead of mqs_free, unfortunately free is #defined to be opal_free
which then becomes an undefined symbol.

> The current trunk and 1.5 branch should have this issue extricated from 
> it.  However, this seems to always creep in every so often.  So the 
> below test is greatly appreciated.  Also, have you ran this test against 
> the trunk and 1.5, yet (is my belief of things are clean there correct)?

I've run it against a slightly stale version of the trunk which is as
you say clean currently.  I'm not sure where I'd get a 1.5 branch from
but if you point me to it I can test this as well.

Ashley,

-- 

Ashley Pittman, Bath, UK.

Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk

Re: [OMPI devel] [patch] Verifying the message queue DLL build

[Terry Dontje]

Ashley Pittman wrote:

I've seen several cases now where people have functional, installed MPI
libraries yet when they've come to use padb they have discovered a build
problem with the Message Queue DLL which prevents it from working.

  
The cases I've seen this happen is with the Sun Studio compiler when a 
source file pulls in a header that defines an inline static function 
that uses some extern symbols but the inline static function itself is 
never used.  For some reason Sun Studio (I believe I've seen another 
compiler do this also pgi or pathscale I think) decides to make those 
extern symbols unresolved instead of just ignoring them.


The current trunk and 1.5 branch should have this issue extricated from 
it.  However, this seems to always creep in every so often.  So the 
below test is greatly appreciated.  Also, have you ran this test against 
the trunk and 1.5, yet (is my belief of things are clean there correct)?


thanks,

--td


The most common problem is unresolved symbols in the dll meaning the
debugger cannot dlopen it or in some cases can only dlopen it with
RTLD_LAZY which introduces other problems.

Attached is a patch to the OpenMPI sources which adds a simple test
program, to be built and run as part of the build procedure that
verifies the dll can be loaded without error.

The test program itself is good, I'm less happy about the autoconf
integration, it adds a check-local target in the debuggers makefile (the
only one in the source tree) which fails if there is a problem with the
DLL, this causes "make check" to fail however this isn't run by either
"make" or "make install".  As such it's a step forward but it would be
better if the test was performed in the make stage, I haven't figured
out how to do this however.

Ashley,

  



___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel

[OMPI devel] [patch] Verifying the message queue DLL build

[Ashley Pittman]

I've seen several cases now where people have functional, installed MPI
libraries yet when they've come to use padb they have discovered a build
problem with the Message Queue DLL which prevents it from working.

The most common problem is unresolved symbols in the dll meaning the
debugger cannot dlopen it or in some cases can only dlopen it with
RTLD_LAZY which introduces other problems.

Attached is a patch to the OpenMPI sources which adds a simple test
program, to be built and run as part of the build procedure that
verifies the dll can be loaded without error.

The test program itself is good, I'm less happy about the autoconf
integration, it adds a check-local target in the debuggers makefile (the
only one in the source tree) which fails if there is a problem with the
DLL, this causes "make check" to fail however this isn't run by either
"make" or "make install".  As such it's a step forward but it would be
better if the test was performed in the make stage, I haven't figured
out how to do this however.

Ashley,

-- 

Ashley Pittman, Bath, UK.

Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk
Index: ompi/debuggers/dlopen_test.c
===
--- ompi/debuggers/dlopen_test.c	(revision 0)
+++ ompi/debuggers/dlopen_test.c	(revision 0)
@@ -0,0 +1,40 @@
+
+#include 
+#include 
+
+int main (int argc, char *argv[]) {
+	
+	char *filename = NULL;
+	void *dlhandle;
+	
+	if ( argc > 1 ) {
+		filename = argv[1];
+	} else {
+		printf("You must supply a filename to open\n");
+		return 10;
+	}
+
+	printf("Trying to dlopen file %s\n",filename);
+
+	dlhandle = dlopen(filename,RTLD_NOW);
+
+	if ( dlhandle ) {
+		printf("File opened with RTLD_NOW, all passed\n");
+		return 0;
+	}
+
+	printf("Failed to open with RTLD_NOW: %s\n",dlerror());
+	
+	printf("Retrying with RTLD_LAZY\n");
+
+	dlhandle = dlopen(filename,RTLD_LAZY);
+
+	if ( dlhandle ) {
+		printf("File opened with RTLD_LAZY\n");
+		return 1;
+	}
+
+	printf("Failed to open with RTLD_LAZY: %s\n",dlerror());
+
+	return 2;
+}
Index: ompi/debuggers/Makefile.am
===
--- ompi/debuggers/Makefile.am	(revision 22102)
+++ ompi/debuggers/Makefile.am	(working copy)
@@ -19,6 +19,7 @@

 noinst_LTLIBRARIES = libdebuggers.la libompi_debugger_canary.la
 pkglib_LTLIBRARIES = libompi_dbg_msgq.la
+check_PROGRAMS = dlopen_test

 # This is not quite in the Automake spirit, but we have to do it.
 # Since the totalview portion of the library must be built with -g, we
@@ -36,6 +37,13 @@
 ompi_common_dll_defs.h \
 msgq_interface.h ompi_msgq_dll_defs.h

+dlopen_test_SOURCES = dlopen_test.c
+
+check-local:
+	./dlopen_test$(EXEEXT) .libs/libompi_dbg_msgq.so
+
+dlopen_test_CFLAGS = -ldl
+
 libdebuggers_la_SOURCES = \
 $(headers) \
 ompi_debuggers.c

Re: [OMPI devel] Crash when using MPI_REAL8

[Sylvain Jeaugey]

Thanks Rainer for the patch. I confirm it solves my testcase as well as 
the real application that triggered the bug.


Sylvain

On Mon, 7 Dec 2009, Rainer Keller wrote:


Hello Sylvain,

On Friday 04 December 2009 02:27:22 pm Sylvain Jeaugey wrote:

There is definetly something wrong in types.

Yes, the new ids for optional Fortran datatypes are wrong.

So, as with other Fortran types, IMHO they need to map to C types, aka the IDs
should map. Therefore, we should _not_ increase the number of predefined types
-- these are fixed as representable by C...

The below patch does just that and fixes Your testcase!

George, what do You think? Could You check, please?

Best regards,
Rainer

PS: Yes, You're perfectly right, that the number of Fortran tests (esp. with
regard to optional ddt) are too low.
Several features of MPI (MPI-2 are not well represented in MTT).
--

Rainer Keller, PhD  Tel: +1 (865) 241-6293
Oak Ridge National Lab  Fax: +1 (865) 241-4811
PO Box 2008 MS 6164   Email: kel...@ornl.gov
Oak Ridge, TN 37831-2008AIM/Skype: rusraink

Re: [OMPI devel] Question about ompi_proc_t

[Pavel Shamis (Pasha)]

George,
Actually My original question was correct.

In the ompi code base I found ONLY two places where we "use" the structure.
Actually we only assign values for the pointer in DR and CM PML:

ompi/mca/pml/cm/pml_cm.c:145:procs[i]->proc_pml = (struct 
mca_pml_base_endpoint_t*) endpoints[i];
ompi/mca/pml/dr/pml_dr.c:264:procs[i]->proc_pml = (struct 
mca_pml_base_endpoint_t*) endpoint;


I do not see any struct definiton/declaration mca_pml_base_endpoint_t in 
the OMPI code at all.


But I do see the "struct mca_pml_endpoint_t;" declaration in pml.h. As 
well, I comment that says: "A pointer to an mca_pml_endpoint_t is 
maintained on each ompi_proc_t". So it looks that the idea was to use 
use mca_pml_endpoint_t on the ompi_proc_t and not 
mca_pml_base_endpoint_t, is not it ?


Thanks !

Pasha

George Bosilca wrote:

Actually your answer is correct. The endpoint is defined down below in the PML. 
In addition, I think only the MTL and the DR PML use it, all OB1 derivative 
completely ignore it.

  george.

On Dec 7, 2009, at 08:30 , Timothy Hayes wrote:

  

Sorry, I think I read your question too quickly. Ignore me. :-)

2009/12/7 Timothy Hayes 
Is it not a forward definition and then defined in the PML components 
individually based on their own requirements?

2009/12/7 Pavel Shamis (Pasha) 

In the ompi_proc_t structure (ompi/proc/proc.h:54) we keep pointer to proc_pml - "struct 
mca_pml_base_endpoint_t* proc_pml" . I tired to find definition for "struct 
mca_pml_base_endpoint_t" , but I failed. Does somebody know where is it defined ?

Regards,
Pasha
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel



___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel