George Bosilca writes:
> There is a whole page on valgrind web page about this topic. Please
> read http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress
> for more information.
Even better, Ralph (et al.) is if we could just make valgrind think
this is defined memory. One c
On Mon, 2009-06-08 at 23:41 -0600, tom fogal wrote:
> George Bosilca writes:
> > There is a whole page on valgrind web page about this topic. Please
> > read http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress
> > for more information.
>
> Even better, Ralph (et al.) is if
This is worth adding to the FAQ.
On Jun 9, 2009, at 2:31 AM, Ashley Pittman wrote:
On Mon, 2009-06-08 at 23:41 -0600, tom fogal wrote:
> George Bosilca writes:
> > There is a whole page on valgrind web page about this topic.
Please
> > read http://valgrind.org/docs/manual/manual-core.html#m
Hi
I made a suppression file for the irrelevant memory leaks of ompi:
I make no claim that it catches all possible ones, but it catches all
that appear in my code.
{
OMPI_Leaks-init-malloc
Memcheck:Leak
fun:malloc
...
fun:PMPI_Init
...
fun:main
}
{
OMPI_Leaks-init-malloc2
Memch
I should add that the "..." are verbatim, not ellipses which indicate
that i left something out!
On Tue, Jun 9, 2009 at 3:43 PM, jody wrote:
> Hi
> I made a suppression file for the irrelevant memory leaks of ompi:
> I make no claim that it catches all possible ones, but it catches all
> that app
Terry Frankcombe a écrit :
> I'm no SGE expert. But don't you have a PE available that simply
> allocates nodes and calls your script? Then you can specify in your
> script any mpirun you want, and it all should still work.
> Alternatively, can't you shut down the SGE-called mpirun as the first
>
Hi Francois,
I am not familiar with the internals of the OMPI code. Are you sure,
however, that threads are fully supported yet? I was under the
impression that thread support was still partial.
Can anyone else comment?
Scott
On Jun 8, 2009, at 8:43 AM, François Trahay wrote:
Hi,
I'm en
Hi all,
I'm trying to get MPI_Lookup_name working.
The codes are working fine with mpich2.
I'm using ompi-1.3.2 (r21054, from the tar version)
Here's the error message :
[homard:26336] *** An error occurred in MPI_Lookup_name
[homard:26336] *** on communicator MPI_COMM_WORLD
[homard:26336] *** M
It works fine, but you didn't specify the ompi-server uri correctly. On the
mpirun cmd line, you needed to specify it as "file:test" so we know that it
is a filename and not something else. Here is the mpirun help output:
"Specify the URI of the Open MPI server, or the name of the file (specified
Ralph Castain a écrit :
It works fine, but you didn't specify the ompi-server uri correctly.
On the mpirun cmd line, you needed to specify it as "file:test" so we
know that it is a filename and not something else. Here is the mpirun
help output:
"Specify the URI of the Open MPI server, or the
jody writes:
> I made a suppression file for the irrelevant memory leaks of ompi: I
> make no claim that it catches all possible ones, but it catches all
> that appear in my code.
[snip]
Thanks, Jody.
What are the chances something like this could be added / maintained in
the OpenMPI tree? It
I can't speak to all of the OMPI code, but I can certainly create a new
configure option --valgrind-friendly that would initialize the OOB comm
buffers and other RTE-related memory to eliminate such warnings.
I would prefer to configure it out rather than adding a bunch of "if-then"
checks for env
I have a serial code that repeatedly calls OpenMPI mpirun on a parallel
code. Each run takes either 10 or 100 seconds, and the whole process
repeated
thousands of times. Each invocation of mpirun is gradually slower
(adding maybe
15-20 seconds per run after about 1000 runs). This is with Op
On Tue, 2009-06-09 at 12:01 -0600, Ralph Castain wrote:
> I can't speak to all of the OMPI code, but I can certainly create a
> new configure option --valgrind-friendly that would initialize the OOB
> comm buffers and other RTE-related memory to eliminate such warnings.
>
> I would prefer to confi
Ralph Castain writes:
> I can't speak to all of the OMPI code, but I can certainly create
> a new configure option --valgrind-friendly that would initialize
> the OOB comm buffers and other RTE-related memory to eliminate such
> warnings.
That would be excellent, thank you for offering.
> I woul
We have done similar things in our code base, and I may explore that option
here. Doing it in too many places gets to be icky, though, so I'll have to
look at it before deciding on the course of action.
Thanks!
Ralph
On Tue, Jun 9, 2009 at 12:13 PM, tom fogal wrote:
> Ralph Castain writes:
>
It is not as simple as it sound. The problem is not coming from the
OOB, it just surface there. The header we add on the wire is well
aligned and completely initialized. The problem is coming from the
buffer that the OOB TCP is asked to send, buffer which is only
partially initialized. This
Sounds like the better solution to me! And far less work... ;-)
Perhaps if we post a valgrind suppression file on the OMPI web site,
and/or include it in our releases, we could help users avoid the
problems. We could update the file as more areas are identified so we
eventually have a reall
18 matches
Mail list logo
