-- Forwarded message --
From: Brian Blank
List-Post: devel@lists.open-mpi.org
Date: Fri, May 1, 2009 at 11:54 AM
Subject: Re: [OMPI devel] Fwd: Purify found bugs inside open-mpi library
To: Terry Dontje
Hi Terry,
I did a memset() prior to the call to processor_info(), and the U
Ugh - I'll fix today.
Brian
On Fri, 1 May 2009, Ralph Castain wrote:
BTW: when compiling Brian's change, I got a warning about comparing
signed and unsigned. Sure enough, I found that the communicator id is
defined as an unsigned int, while the PML is treating it as a *signed*
int.
We need to
The problem is actually broader than OS-X. MTT shows failures on every
platform.
There are two problems:
1. OS-X is missing a string.h header in pstat/darwin module
2. "make check" in the test area is failing due to the datatype tests
missing string.h in their headers
I have fixed these, so hop
Arrgh! Sorry, my bad. I must have been linked against an old version
or something. When I recompiled the output went away.
Greg
On May 1, 2009, at 10:09 AM, Ralph Castain wrote:
Interesting - I'm not seeing this behavior:
graywolf54:trunk rhc$ mpirun -n 3 --xml --display-map hostname
The first tarball since the header file reduction was tested on MTT
last night. We had across-the-board breakage on OS X:
http://www.open-mpi.org/mtt/index.php?do_redir=1029
Can someone please fix?
Thanks.
--
Jeff Squyres
Cisco Systems
Interesting - I'm not seeing this behavior:
graywolf54:trunk rhc$ mpirun -n 3 --xml --display-map hostname
graywolf54.lanl.gov
graywolf54.lanl.gov
graywolf54.lanl.gov
graywolf54:trunk rhc$
Can you tell me more about when you see this? Note that the display-m
BTW: when compiling Brian's change, I got a warning about comparing signed
and unsigned. Sure enough, I found that the communicator id is defined as an
unsigned int, while the PML is treating it as a *signed* int.
We need to get this corrected - which way do you want it to be?
I will add this req
Hmmm...no, that's a bug. I'll fix it.
Thanks!
On Fri, May 1, 2009 at 7:24 AM, Greg Watson wrote:
> Ralf,
>
> I've just noticed that if I use '-xml -display-map', I get the xml version
> of the map and then the non-xml version is sent to stderr (wrapped in xml
> tags). Was this by design? In my
Ralf,
I've just noticed that if I use '-xml -display-map', I get the xml
version of the map and then the non-xml version is sent to stderr
(wrapped in xml tags). Was this by design? In my view it would be
better to suppress the non-xml map altogether if the -xml option. 1.4
seems to do th
I'm not entirely sure if David is going to be in today, so I will answer for
him (and let him correct me later!).
This code is indeed representative of what the app is doing. Basically, the
user repeatedly splits the communicator so he can run mini test cases before
going on to the larger computat
David,
is this code representative for what your app is doing? E.g. you have a
base communicator (e.g. MPI_COMM_WORLD) which is being 'split', freed
again, split, freed again etc. ? i.e. the important aspect is that the
same 'base' communicator is being used for deriving new communicators
aga
11 matches
Mail list logo
