Re: [OMPI devel] [OMPI svn] svn:open-mpi r12092
I'm usually not in favor of such commits. They are very development
specific, and to be honest very user specific. I use valgrind on a
regular basis, but that's not a reason to commit my changes into the
trunk. However, I think it can be interesting to allow us to prepend
something to the command line.
If you ask me how I use valgrind I will tell you that I spawn an
xterm with valgrind inside (and let vagrind start gdb for me when it
detect some memory problems). If we want to have a generic solution
that will work for everybody let's create a MCA parameter which
contain a string that will be prepended to all orted command lines.
So instead of starting "orted $args" we will start "$orte_prepend
orted $args". That way everybody can configure the spawning process
exactly as they want.
Thanks,
george.
On Oct 11, 2006, at 1:48 PM, r...@osl.iu.edu wrote:
Author: rhc
Date: 2006-10-11 13:48:41 EDT (Wed, 11 Oct 2006)
New Revision: 12092
Modified:
trunk/orte/mca/pls/rsh/pls_rsh_component.c
Log:
Add the proper valgrind params
Modified: trunk/orte/mca/pls/rsh/pls_rsh_component.c
==
--- trunk/orte/mca/pls/rsh/pls_rsh_component.c (original)
+++ trunk/orte/mca/pls/rsh/pls_rsh_component.c 2006-10-11 13:48:41
EDT (Wed, 11 Oct 2006)
@@ -110,6 +110,7 @@
{
int tmp;
char *ctmp;
+char *valgrind = "valgrind --verbose --log-file=debug.out --
num-callers=100 --tool=memcheck --trace-children=no --leak-
check=full --show-reachable=yes";
mca_base_component_t *c =
&mca_pls_rsh_component.super.pls_version;
/* initialize globals */
@@ -158,7 +159,7 @@
"Whether or not to launch the
orteds under valgrind (Linux *only*)",
false, false, (int)false, &tmp);
if (tmp) {
-asprintf(&ctmp, "valgrind %s", mca_pls_rsh_component.orted);
+asprintf(&ctmp, "%s %s", valgrind,
mca_pls_rsh_component.orted);
free(mca_pls_rsh_component.orted);
mca_pls_rsh_component.orted = ctmp;
}
___
svn mailing list
s...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/svn
[OMPI devel] Shared memory file changes
Hi all - A couple of weeks ago, I committed some changes to the trunk that greatly reduced the size of the shared memory file for small numbers of processes. I haven't heard any complaints (the non-blocking send/receive issue is at proc counts greater than the size this patch affected). Anyone object to moving this to the v1.2 branch (with reviews, of course). Brian -- Brian Barrett Graduate Student, Open Systems Lab, Indiana University http://www.osl.iu.edu/~brbarret/
Re: [OMPI devel] Shared memory file changes
Brian, The way the resize was done, led to unexpected behaviors. It was not possible to know what the result of the resize was ... might be smaller or bigger depending on the value on the stack at the call). I commit a fix this morning. Let's wait few days before moving the 2 commits into the 1.2. Thanks, george. On Oct 11, 2006, at 5:09 PM, Brian W. Barrett wrote: Hi all - A couple of weeks ago, I committed some changes to the trunk that greatly reduced the size of the shared memory file for small numbers of processes. I haven't heard any complaints (the non-blocking send/receive issue is at proc counts greater than the size this patch affected). Anyone object to moving this to the v1.2 branch (with reviews, of course). Brian -- Brian Barrett Graduate Student, Open Systems Lab, Indiana University http://www.osl.iu.edu/~brbarret/ ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
[OMPI devel] IPv6 in btl/tcp
Hi, this mail starts like all the others before ;): I'm glad to announce a first working version of btl/tcp with both, IPv4 and IPv6 support. adi@ipc654:~/ompi/trunk/test$ ruby ringtest.rb Loaded suite ringtest Started 0: sending message (0) to 1 1: got message (1) from 0, sending to 2 2: got message (2) from 1, sending to 0 0: got message (2) from 2 3 additional processes aborted (not shown) This ringtest was done in an IPv6-only environment, so process launching (orte) and MPI communication were done via IPv6. Unfortunately, the process crashed afterwards, but as mentioned above, it's the very first version. (when I write these lines, the svn checkin is only three minutes old) The ringtest also works fine in plain IPv4 environments and mixed environments within the same cluster. It fails on mixed multi-cluster setups and heterogenous OSs, but I'm going to fix these issues on Saturday (or next week). (I'm currently passing complete struct sockaddr_storages from btl_tcp_addr.h to the pml, thus giving different sizeof (mca_btl_tcp_addr_t) in btl_tcp_proc.c: (if(0 != (size % sizeof(mca_btl_tcp_addr_t That's obviously wrong.) Let's see... -- mail: a...@thur.de http://adi.thur.de PGP: v2-key via keyserver Q: Was können Frauen, was Männer nicht können? A: Kinder kriegen, Periode kriegen, nach dem Tod noch Sex haben
Re: [OMPI devel] [OMPI svn] svn:open-mpi r12092
That's fine with me too. I only entered this because we needed something to
help check memory corruption on the backend, and not every environment will
support the xterm approach (especially around here). I was of two minds
about it, but needed something in the code that could be moved from computer
to computer for testing.
I can modify it accordingly.
On 10/11/06 12:28 PM, "George Bosilca" wrote:
> I'm usually not in favor of such commits. They are very development
> specific, and to be honest very user specific. I use valgrind on a
> regular basis, but that's not a reason to commit my changes into the
> trunk. However, I think it can be interesting to allow us to prepend
> something to the command line.
>
> If you ask me how I use valgrind I will tell you that I spawn an
> xterm with valgrind inside (and let vagrind start gdb for me when it
> detect some memory problems). If we want to have a generic solution
> that will work for everybody let's create a MCA parameter which
> contain a string that will be prepended to all orted command lines.
> So instead of starting "orted $args" we will start "$orte_prepend
> orted $args". That way everybody can configure the spawning process
> exactly as they want.
>
>Thanks,
> george.
>
> On Oct 11, 2006, at 1:48 PM, r...@osl.iu.edu wrote:
>
>> Author: rhc
>> Date: 2006-10-11 13:48:41 EDT (Wed, 11 Oct 2006)
>> New Revision: 12092
>>
>> Modified:
>>trunk/orte/mca/pls/rsh/pls_rsh_component.c
>>
>> Log:
>> Add the proper valgrind params
>>
>>
>> Modified: trunk/orte/mca/pls/rsh/pls_rsh_component.c
>> ==
>>
>> --- trunk/orte/mca/pls/rsh/pls_rsh_component.c (original)
>> +++ trunk/orte/mca/pls/rsh/pls_rsh_component.c 2006-10-11 13:48:41
>> EDT (Wed, 11 Oct 2006)
>> @@ -110,6 +110,7 @@
>> {
>> int tmp;
>> char *ctmp;
>> +char *valgrind = "valgrind --verbose --log-file=debug.out --
>> num-callers=100 --tool=memcheck --trace-children=no --leak-
>> check=full --show-reachable=yes";
>> mca_base_component_t *c =
>> &mca_pls_rsh_component.super.pls_version;
>>
>> /* initialize globals */
>> @@ -158,7 +159,7 @@
>> "Whether or not to launch the
>> orteds under valgrind (Linux *only*)",
>> false, false, (int)false, &tmp);
>> if (tmp) {
>> -asprintf(&ctmp, "valgrind %s", mca_pls_rsh_component.orted);
>> +asprintf(&ctmp, "%s %s", valgrind,
>> mca_pls_rsh_component.orted);
>> free(mca_pls_rsh_component.orted);
>> mca_pls_rsh_component.orted = ctmp;
>> }
>> ___
>> svn mailing list
>> s...@open-mpi.org
>> http://www.open-mpi.org/mailman/listinfo.cgi/svn
>
> ___
> devel mailing list
> de...@open-mpi.org
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] Shared memory file changes
Nope. On Oct 11, 2006, at 2:09 PM, Brian W. Barrett wrote: Hi all - A couple of weeks ago, I committed some changes to the trunk that greatly reduced the size of the shared memory file for small numbers of processes. I haven't heard any complaints (the non-blocking send/receive issue is at proc counts greater than the size this patch affected). Anyone object to moving this to the v1.2 branch (with reviews, of course). Brian -- Brian Barrett Graduate Student, Open Systems Lab, Indiana University http://www.osl.iu.edu/~brbarret/ ___ devel mailing list de...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/devel
