[OMPI devel] Envelope of HINDEXED_BLOCK

$ mpicc type_hindexed_block.c $ ./a.out ni=7 na=5 nd=1 combiner=18 -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Science and Technology (KAUST) http

[OMPI devel] Comm_split_type(COMM_SELF, MPI_UNDEFINED, ...)

: invalid argument of some other kind [kw2060:9865] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, [kw2060:9865] ***and potentially your MPI job) -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numer

[OMPI devel] MPI calls in callback functions during MPI_Finalize()

able to aggregate error messages, and not able to guarantee that all other processes were killed! -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University o

[OMPI devel] malloc 0 warnings

: Request for 0 bytes (osc_rdma_active_target.c, 74) -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Science and Technology (KAUST) http://numpor.kaust.ed

Re: [OMPI devel] Envelope of HINDEXED_BLOCK

ig Could it be related to automake 13 instead of 12 ? -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Science and Technology (KAUST) http://numpor.kaust

Re: [OMPI devel] MPI calls in callback functions during MPI_Finalize()

re callbacks you what to run specifically at MPI_Finalize(). Caching duplicated communicators is a key feature in many libraries. How do you propose to handle the deallocation of the duped communicators when COMM_WORLD is involved? -- Lisandro Dalcin Research Scientist Computer, Electric

Re: [OMPI devel] MPI calls in callback functions during MPI_Finalize()

to cleanup your communicators is already bad habit, > which is rightfully punished by Open MPI. > After much thinking about it, I must surrender :-), you were right. Sorry for the noise. -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & En

Re: [OMPI devel] malloc 0 warnings

On 27 August 2014 02:38, Jeff Squyres (jsquyres) wrote: > If you have reproducers, yes, that would be most helpful -- thanks. > OK, here you have something to start. To be fair, this is a reduction with zero count. I have many other tests for reductions with zero count that

Re: [OMPI devel] malloc 0 warnings

On 27 August 2014 02:38, Jeff Squyres (jsquyres) wrote: > If you have reproducers, yes, that would be most helpful -- thanks. > Here you have another one... $ cat igatherv.c #include int main(int argc, char *argv[]) { signed char a=1,b=2; int rcounts[1] = {0}; int

[OMPI devel] Valgrind warning in MPI_Win_allocate[_shared]()

goto error; } if (blocking_fence) { -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Science and Technology (KAUST) http://numpor.kaust.edu.sa/ 4700 King Abdull

Re: [OMPI devel] Different behaviour with MPI_IN_PLACE in MPI_Reduce_scatter() and MPI_Ireduce_scatter()

f[0]= 1 expected: 1 $ mpicc -DNBCOLL=1 ireduce_scatter.c && mpiexec -n 1 ./a.out [0] rbuf[0]=60 expected: 1 -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah

Re: [OMPI devel] Neighbor collectives with periodic Cartesian topologies of size one

On 25 September 2014 20:50, Nathan Hjelm <hje...@lanl.gov> wrote: > On Tue, Aug 26, 2014 at 07:03:24PM +0300, Lisandro Dalcin wrote: >> I finally managed to track down some issues in mpi4py's test suite >> using Open MPI 1.8+. The code below should be enough to reproduc

Re: [OMPI devel] Different behaviour with MPI_IN_PLACE in MPI_Reduce_scatter() and MPI_Ireduce_scatter()

[1] rbuf[1]= 0 expected: 0 $ mpiexec -n 1 ./a.out [0] rbuf[0]= 0 expected: 1 The last one is wrong. Not sure what's going on. Am I missing something? -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Po

[OMPI devel] Warnings about malloc(0) in debug build

bytes (coll_libnbc_ireduce_scatter_block.c, 67) malloc debug: Request for 0 bytes (nbc_internal.h, 505) malloc debug: Request for 0 bytes (osc_rdma_active_target.c, 74) malloc debug: Request for 0 bytes (osc_rdma_active_target.c, 76) -- Lisandro Dalcin Research Scientist Computer

[OMPI devel] Issues with MPI_Type_create_f90_{real|complex}

(malloc.c:101) ==1025==by 0x4C739E3: ompi_datatype_set_args (ompi_datatype_args.c:121) ==1025==by 0x4CC8636: PMPI_Type_create_f90_complex (ptype_create_f90_complex.c:110) ==1025==by 0x4008BA: main (in /home/dalcinl/Devel/BUGS-MPI/openmpi/a.out) ==1025== -- Lisandro Dalcin

[OMPI devel] Build regression: VampirTrace libraries built with debug symbols and no optimization

e ompi/contrib/vt looks ok, but the all the others in subdirs under ompi/contrib/vt are not, this smells as a build regression your are likely not aware of. -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media

Re: [OMPI devel] Build regression: VampirTrace libraries built with debug symbols and no optimization

Open MPI 1.8.6 was released, and this issue seems to be still there. Linux binaries are near 3 times larger: https://binstar.org/mpi4py/openmpi/files On 8 May 2015 at 06:47, Lisandro Dalcin <dalc...@gmail.com> wrote: > A build of 1.8.4 with just "./configure --prefix=..." produ

[OMPI devel] Regressions: MPI_Win_{start|post}() with MPI_GROUP_EMPTY

The attached test code used to work in 1.8.5 and below, but they are failing in 1.8.6 with MPI_ERR_INTERN (tested in OS X). -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor)

Re: [OMPI devel] Bug

t all of MPI. Also, my testsuite tests for corner cases and "stupid" code paths (e.g. create and destroy something without ever using it for anything useful) that evidently no one out there is testing. -- Lisandro Dalcin Research Scientist Computer, Electrical and

Re: [OMPI devel] Bug

ally you get a failure that is not Open MPI's fault. -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Science and Technology (KAUST) http://numpor.kaust.

[OMPI devel] malloc(0) warning with 1.8.7

(coll_libnbc_ireduce_scatter_block.c, 67) -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Science and Technology (KAUST) http://numpor.kaust.edu.sa/ 4700 King Abdullah Univer

[OMPI devel] 1.8.7 release tarball versus v1.8.7 tag in ompi-release repo

/oob_tcp_connection.c and openmpi-1.8.7/orte/mca/oob/tcp/oob_tcp_connection.c differ Files ompi-release/VERSION and openmpi-1.8.7/VERSION differ -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (Nu

Re: [OMPI devel] malloc(0) warning with 1.8.7

ca_coll_base_module_2_1_0_t -> mca_coll_base_module_2_0_0_t. -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Science and Technology (KAUST) http://numpor.kaust.edu.sa/ 4700 K

Re: [OMPI devel] Build regression: VampirTrace libraries built with debug symbols and no optimization

On 20 June 2015 at 20:48, Bert Wesarg <bert.wes...@tu-dresden.de> wrote: > Lisandro, > > On 06/20/2015 05:03 AM, Lisandro Dalcin wrote: >> >> Open MPI 1.8.6 was released, and this issue seems to be still there. >> Linux binaries are near 3 times larger: >> h

[OMPI devel] Issues with nonblocking collectives for zero-sized messages

in this communicator will now abort, [kw2060:25212] ***and potentially your MPI job) -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (NumPor) King Abdullah University of Sci

Re: [OMPI devel] Issues with nonblocking collectives for zero-sized messages

On 10 November 2015 at 11:35, Nick Papior <nickpap...@gmail.com> wrote: > Please try the patch from this post: > http://www.open-mpi.org/community/lists/users/2015/11/28030.php > It worked. Thanks. -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathem

[OMPI devel] malloc(0) warnings in post/wait and start/complete calls with GROUP_EMPTY

(osc_pt2pt_active_target.c, 76) malloc debug: Request for 0 bytes (osc_pt2pt_active_target.c, 78) malloc debug: Request for 0 bytes (osc_pt2pt_active_target.c, 76) malloc debug: Request for 0 bytes (osc_pt2pt_active_target.c, 78) -- Lisandro Dalcin Research Scientist Computer, Electrical

Re: [OMPI devel] malloc(0) warnings in post/wait and start/complete calls with GROUP_EMPTY

nt away, valgrind didn't complain. > btw, how do you get these warnings automatically ? > ./configure --enable-debug --enable-mem-debug ... PS: Running a trivial program with MPI_Init()/Finalize() shows a few memory leaks if run under valgrind. Just FYI, in case you want to take a clos

[OMPI devel] MPI_Get_address() with MPI_BOTTOM

[kw2060:18815] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, [kw2060:18815] ***and potentially your MPI job) -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media Center (Nu

[OMPI devel] Failure calling MPI_Type_set_attr(datatype, keyval, NULL)

Despite working for communicators and windows, setting a NULL attribute value in datatypes fails with MPI_ERR_ARG. Run the attached test case to reproduce. -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Po

Re: [OMPI devel] MPI_Get_address() with MPI_BOTTOM

sue too quickly :-) I added some additional comments. PS: Should I go to GitHub directly next time? Or you still prefer bug reports in the mailing list? -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Numerical Porous Media C

[OMPI devel] C type of MPI_UNWEIGHTED and MPI_WEIGHTS_EMPTY

) /* unweighted graph */ #define MPI_WEIGHTS_EMPTY((int *) 3) /* empty weights */ PS: While the current definition is kind of harmless for C, it is likely wrong for C++. -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences

[OMPI devel] MPI_Group_intersection: malloc(0) warning with 2.0.0rc3

debug: Request for 0 bytes (group/group.c, 456) -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.kaust.edu.sa/

[OMPI devel] 2.0.0rc3 MPI_Comm_split_type()

ception: MPI_ERR_ARG: invalid argument of some other kind -- Lisandro Dalcin Research Scientist Computer, Electrical and Mathematical Sciences & Engineering (CEMSE) Extreme Computing Research Center (ECRC) King Abdullah University of Science and Technology (KAUST) http://ecrc.

[OMPI devel] MPI_Type_free(MPI_BYTE) not failing after MPI_Win_create()

{ MPI_Datatype byte = MPI_BYTE; MPI_Type_free(); } MPI_Finalize(); return 0; } -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

[OMPI devel] VampirTrace and MPI_Init_thread()

at arrived at my inbox months ago). -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

Re: [OMPI devel] VampirTrace and MPI_Init_thread()

On 13 August 2010 05:22, Matthias Jurenz <matthias.jur...@tu-dresden.de> wrote: > On Wednesday 11 August 2010 23:16:50 Lisandro Dalcin wrote: >> On 11 August 2010 03:12, Matthias Jurenz <matthias.jur...@tu-dresden.de> > wrote: >> > Hello Lisandro, >> > &

[OMPI devel] MPI_Mrecv(..., MPI_STATUS_IGNORE) in Open MPI 1.7.1

] Failing at address: (nil) ... -- Lisandro Dalcin --- CIMEC (INTEC/CONICET-UNL) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1011) Tel/Fax: +54-342-4511169

[OMPI devel] Missing MPI 3 definitions

could simply ignore the info handle, and the second could just return a brand new empty info handle (well, unless you implemented MPI_Comm_dup_with_info() to actually use the info hints). -- Lisandro Dalcin --- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El

[OMPI devel] Missing error strings for MPI_ERR_RMA_XXX error classes

RED The comment is wrong, the last predefined error class is MPI_ERR_RMA_SHARED and not MPI_ERR_RMA_FLAVOR. -- Lisandro Dalcin --- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-

[OMPI devel] querying Op commutativity for predefined reduction operations.

] *** on communicator MPI_COMM_WORLD [kw2060:19303] *** MPI_ERR_OP: invalid reduce operation [kw2060:19303] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, [kw2060:19303] ***and potentially your MPI job) -- Lisandro Dalcin --- CIMEC (UNL/CONICET) Predio CONICET

[OMPI devel] Win_fence() with assertion=MPI_MODE_NOPRECEDE|MPI_MODE_NOSUCCEED

, [kw2060:19890] ***and potentially your MPI job) [dalcinl@kw2060 openmpi]$ -- Lisandro Dalcin --- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

[OMPI devel] MPI_Type_create_hindexed_block() segfaults

] /lib64/libc.so.6(__libc_start_main+0xf5)[0x327bc21d65] [kw2060:20304] [ 6] ./a.out[0x4006f9] [kw2060:20304] *** End of error message *** Segmentation fault (core dumped) -- Lisandro Dalcin --- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000

[OMPI devel] Issues with MPI_Add_error_class()

:20883] *** reported by process [140737332576257,0] [kw2060:20883] *** on communicator MPI_COMM_WORLD [kw2060:20883] *** MPI_ERR_ARG: invalid argument of some other kind [kw2060:20883] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, [kw2060:20883] ***and potentially your MPI job)

[OMPI devel] Different behaviour with MPI_IN_PLACE in MPI_Reduce_scatter() and MPI_Ireduce_scatter()

rbuf[2]= 1 expected: 1 [2] rbuf[0]= 3 expected: 3 [2] rbuf[1]= 1 expected: 1 [2] rbuf[2]= 1 expected: 1 -- Lisandro Dalcin --- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

[OMPI devel] MPI_Comm_create_group()

: ompi_mpi_errors_are_fatal_comm_handler (errhandler_predefined.c:69) ==22675==by 0x4C4A63E: ompi_errhandler_invoke (errhandler_invoke.c:53) ==22675==by 0x4C81E81: PMPI_Comm_create_group (pcomm_create_group.c:79) ==22675==by 0x4008FF: main (in /home/dalcinl/Devel/BUGS-MPI/openmpi/a.out) ==22675== -- Lisandro Dalcin

[OMPI devel] likely bad return from MPI_File_c2f

Try to run the trivial program below. I MPI_File_c2f(MPI_FILE_NULL) returns "-1" (minus one), however it seems the routine should return "0" (zero). #include #include int main() { MPI_Fint i; MPI_File f; MPI_Init(0,0); i = MPI_File_c2f(MPI_FILE_NULL);

[OMPI devel] possible bugs and unexpected values in returned errors classes

Below a list of stuff that I've got by running mpi4py testsuite. Never reported them before just because some of them are not actually errors, but anyway, I want to raise the discussion. - Likely bugs (regarding my interpretation of the MPI standard) 1) When passing MPI_REQUEST_NULL,

Re: [OMPI devel] possible bugs and unexpected values in returned errors classes

On Thu, Feb 12, 2009 at 10:02 PM, Jeff Squyres <jsquy...@cisco.com> wrote: > On Feb 11, 2009, at 8:24 AM, Lisandro Dalcin wrote: > >> Below a list of stuff that I've got by running mpi4py testsuite. Never >> reported them before just because some of them are not actually

Re: [OMPI devel] possible bugs and unexpected values in returned errors classes

Just found something new to comment after diving into the actual sources On Thu, Feb 12, 2009 at 10:02 PM, Jeff Squyres <jsquy...@cisco.com> wrote: > On Feb 11, 2009, at 8:24 AM, Lisandro Dalcin wrote: >> >> 1) When passing MPI_COMM_NULL, MPI_Comm_get_errhandler() fails w

[OMPI devel] MPI_Accumulate() with MPI_PROC_NULL target rank

The MPI 2-1 standard says: "MPI_PROC_NULL is a valid target rank in the MPI RMA calls MPI_ACCUMULATE, MPI_GET, and MPI_PUT. The effect is the same as for MPI_PROC_NULL in MPI point-to-point communication. After any RMA operation with rank MPI_PROC_NULL, it is still necessary to finish the RMA

[OMPI devel] more bug/comments for current trunk

Disclaimer: this is for trunk svn up'ed yesterday. The code below should fail with ERR_COMM, but it succeed... #include int main(int argc, char **argv) { int *value, flag; MPI_Init(NULL, NULL); MPI_Comm_get_attr(MPI_COMM_NULL, MPI_TAG_UB, , ); MPI_Finalize(); return 0; }

[OMPI devel] Dynamic languages, dlopen() issues, and symbol visibility of libtool ltdl API in current trunk

Hi all.. I have to contact you again about the issues related to dlopen()ing libmpi with RTLD_LOCAL, as many dynamic languages (Python in my case) do. So far, I've been able to manage the issues (despite the "do nothing" policy from Open MPI devs, which I understand) in a more or less portable

Re: [OMPI devel] Dynamic languages, dlopen() issues, and symbol visibility of libtool ltdl API in current trunk

gnu.libtool.patches/9446 >> >> So we would (others can speak up if not) certainly consider such a >> wrapper, but I think we need to wait for the next libtool release >> (unless there is other magic we can do) before it would be usable. >> >> Do others have any other i

[OMPI devel] ompi-trunk: have MPI_REAL2 (if available) but missing MPI_COMPLEX4

Disclaimer: I have almost no experience with Fortran, nor I'm needing this, but anyway (perhaps just as a reminder for you) :-)... Provided that: 1) Open MPI exposes MPI_LOGICAL{1|2|4|8}, and they are not (AFAIK) listed in the MPI standard (I cannot found them in MPI-2.2) 2) The MPI-2.2

Re: [OMPI devel] ompi-trunk: have MPI_REAL2 (if available) but missing MPI_COMPLEX4

support them) are an omission in the 2.2 standard. On Wed, Sep 23, 2009 at 4:33 PM, Lisandro Dalcin <dalc...@gmail.com> wrote: > Disclaimer: I have almost no experience with Fortran, nor I'm needing > this, but anyway (perhaps just as a reminder for you) :-)... > > Provided tha

Re: [OMPI devel] ompi-trunk: have MPI_REAL2 (if available) but missing MPI_COMPLEX4

rep real2 000fe0e0 D ompi_mpi_real2 So if you have support for real(kind=2) in "ompi_mpi_real2" ... Do you still think that it is so hard to support complex(kind=4) ?? Anyway, I see that MPI_REAL2 is never #define'd to _mpi_real2 . >  george. > > On Sep 26, 2009, at 11

[OMPI devel] MPI_Group_{incl|exc} with nranks=0 and ranks=NULL

Currently (trunk, just svn update'd), the following call fails (because of the ranks=NULL pointer) MPI_Group_{incl|excl}(group, 0, NULL, ) BTW, MPI_Group_translate_ranks() has similar issues... Provided that Open MPI accept the combination (int_array_size=0, int_array_ptr=NULL) in other calls,

Re: [OMPI devel] possible bugs and unexpected values in returned errors classes

It seems that this issue got lost. On Thu, Feb 12, 2009 at 9:02 PM, Jeff Squyres <jsquy...@cisco.com> wrote: > On Feb 11, 2009, at 8:24 AM, Lisandro Dalcin wrote: > >> Below a list of stuff that I've got by running mpi4py testsuite. >> >> 4)  When passing MPI_WI

[OMPI devel] failure with zero-length Reduce() and both sbuf=rbuf=NULL

See the code below. The commented-out combinations for sbuf,rbuf do work, but the one passing sbuf=rbuf=NULL (i.e, the uncommented one show below) makes the call fail with MPI_ERR_ARG. #include int main( int argc, char ** argv ) { int ierr; int sbuf,rbuf; MPI_Init(, ); ierr =

Re: [OMPI devel] failure with zero-length Reduce() and both sbuf=rbuf=NULL

On Thu, Dec 10, 2009 at 4:26 PM, George Bosilca wrote: > Lisandro, > > This code is not correct from the MPI standard perspective. The reason is > independent of the datatype or count, it is solely related to the fact that > the MPI_Reduce cannot accept a sendbuf equal to

Re: [OMPI devel] failure with zero-length Reduce() andbothsbuf=rbuf=NULL

eturns in some platforms), or pointer could be NULL (because that's what malloc(0) returns, of because the implemention code special-case things by enforcing ptr=NULL,len=0 for zero-length array instances). As there are different ways to represent a zero-length array using a (ptr,len) pair, I tri

Re: [OMPI devel] failure withzero-lengthReduce()andbothsbuf=rbuf=NULL

avior and standard compliance on MPI implementations is FUNDAMENTAL to develop portable wrappers for other languages... Unfortunately, things are not so easy; mpi4py's source code and testsuite is plenty of "if OMPI" and "if MPICH2"... -- Lisandro Dalcin ---

[OMPI devel] MPI_Win_get_errhandler() and MPI_Win_set_errhandler() do not fail when passing MPI_WIN_NULL

I've reported this long ago (alongside other issues now fixed)... I can see that this is fixed in trunk and branches/v1.5, but not backported to branches/v1.4 Any chance to get this for 1.4.2? Or should it wait until 1.5? -- Lisandro Dalcin --- Centro Internacional de Métodos

Re: [OMPI devel] RFC: ABI break between 1.4 and 1.5 / .so versioning

ow to do this trick, just in case a sysadmin desperately needs the hack because of pressure from some user with ABI issues. -- Lisandro Dalcin --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Con

[OMPI devel] problem with MPI_[Pack|Unpack]_external

I've just catched a problem with packing/unpacking using 'external32' in Linux. The problem seems to be word ordering, I believe you forgot to make the little-endian <-> big-endian conversion somewhere. Below, an interactive session with ipython (sorry, no time to write in C) showing the problem.

[OMPI devel] MPI_XXX_{get|set}_errhandler in general , and for files in particular

Looking at MPI-2 errata document, http://www.mpi-forum.org/docs/errata-20-2.html, is says: Page 61, after line 36. Add the following (paralleling the errata to MPI-1.1): MPI_{COMM,WIN,FILE}_GET_ERRHANDLER behave as if a new error handler object is created. That is, once the error handler is no

[OMPI devel] Fwd: MPI_GROUP_TRANSLATE_RANKS (again)

I've successfully installed the just released 1.1.2. So I go for a new round catching bugs, non standard behavior, or just what could be seen as convenient features. The problem I've reported with MPI_GROUP_TRANSLATE_RANKS was corrected. However, looking at MPI-2 errata documment, it says: Add

[OMPI devel] MPI_BUFFER_ATTACH/DETACH behaviour

As a general idea and following similar MPI concepts, it can be really useful if MPI_BUFFER_ATTACH/DETACH allowed a layered usage, inside modules. That is, inside a call, a library can make a 'detach' and cache it, next 'attach' an internally allocated resource, call BSEND, 'detach' it own

Re: [OMPI devel] [Open MPI] #529: MPI_START* returning OMPI_* error codes

On 10/22/06, Open MPI wrote: #529: MPI_START* returning OMPI_* error codes -+-- Reporter: jsquyres | Owner: Type: defect| Status: new Priority: major | Milestone: Open MPI

Re: [OMPI devel] failures runing mpi4py testsuite, perhaps Comm.Split()

On 7/11/07, George Bosilca wrote: The two errors you provide are quite different. The first one has been addresses few days ago in the trunk (https://svn.open-mpi.org/ trac/ompi/changeset/15291). If instead of the 1.2.3 you use anything after r15291 you will be safe in a

[OMPI devel] COVERITY STATIC SOURCE CODE ANALYSIS

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

[OMPI devel] MPI_APPNUM value for apps not started through mpiexec

Using a fresh (2 hours agoo) update of SVN branch v1.2, I've found that attribute MPI_APPNUM returns -1 (minus one) when an 'sequential' application is not launched through mpiexec. Reading the MPI standard, I understand it should return a non-negative integer if defined, or it should not be

[OMPI devel] MPI_ALLOC_MEM warning when requesting 0 (zero) bytes

If I understand correctly the standard, http://www.mpi-forum.org/docs/mpi-20-html/node54.htm#Node54 MPI_ALLOC_MEM with size=0 is valid ('size' is a nonnegative integer) Then, using branch v1.2, I've got the following warning at runtime: malloc debug: Request for 0 bytes

Re: [OMPI devel] Fwd: [Open MPI] #1101: MPI_ALLOC_MEM with 0 size must be valid

On 7/23/07, Jeff Squyres wrote: Does anyone have any opinions on this? If not, I'll go implement option #1. Sorry, Jeff... just reading this. I think your option #1 is the better. However, I want to warn you about to issues: * In my Linux FC6 box, malloc(0) return

Re: [OMPI devel] MPI_ALLOC_MEM warning when requesting 0 (zero) bytes

On 7/23/07, Jeff Squyres wrote: I think that this will require a little tomfoolery to fix properly because we can't simply return NULL (you can't expect to use the pointer that we return to store anything, but you should be able to expect to be able to dereference it without

Re: [OMPI devel] MPI_ALLOC_MEM warning when requesting 0 (zero) bytes

On 7/25/07, Jeff Squyres wrote: Be sure to read this thread in order -- the conclusion of the thread was that we now actually *do* return NULL, per POSIX advice. OK, I got confused. And now, MPI_Free_mem is going to fail with a NULL pointer? Not sure what POSIX says, but

[OMPI devel] MPI_Win_get_group

The MPI-2 standard says (see bottom of ) MPI_WIN_GET_GROUP returns a duplicate of the group of the communicator used to create the window. associated with win. The group is returned in group. Pease, note the 'duplicate' ... Well, it

Re: [OMPI devel] MPI_Win_get_group

On 7/28/07, Brian Barrett wrote: > In my opinion, we conform to the standard. We reference count the > group, it's incremented on call to MPI_WIN_GROUP, and you can safely > call MPI_GROUP_FREE on the group returned from MPI_WIN_GROUP. Groups > are essentially immutable, so

[OMPI devel] MPI_Comm_free with MPI_COMM_SELF

I tried to free COMM_SELF, and it seems to call the error handler attached to COMM_WORLD. Is this intended? Should'nt OMPI use the error handler to COMM_SELF? As reference, I tried this with MPICH2, and of course the call fails, but using the error handler in COMM_SELF. Again, this is a new

Re: [OMPI devel] MPI_Win_get_group

On 7/29/07, Jeff Squyres <jsquy...@cisco.com> wrote: > On Jul 28, 2007, at 4:41 PM, Lisandro Dalcin wrote: > > > In the mean time, I would prefer to follow the standard as close as > > possible. If not, some external, stupid test suite (like the one I > > have for

[OMPI devel] looking up service

MPI_Lookup_name() is supposed to work on v1.2 branch? I cannot get it working (it fails with MPI_ERR_NAME). -- Lisandro Dalcín --- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo

Re: [OMPI devel] MPI_Win_get_group

On 7/30/07, George Bosilca wrote: > In the data-type section there is an advice to implementors that > state that a copy can simply increase the reference count if > applicable. So, we might want to apply the same logic here ... BTW, you just mentioned other obscure case. Do

Re: [OMPI devel] MPI_Win_get_group

On 7/31/07, Dries Kimpe wrote: > The MPI_File_get_view description in the standard has some issues related > to copies and named datatypes: > > see > http://www-unix.mcs.anl.gov/~gropp/projects/parallel/MPI/mpi-errata/discuss/fileview/fileview-1-clean.txt Indeed, your

Re: [OMPI devel] MPI_Win_get_group

On 7/31/07, Jeff Squyres wrote: > Just curious -- why do you need to know if a handle refers to a > predefined object? If I understand correctly, new handles shoud be freed in order to do not leak things, to follow good programming practices, and being completelly sure a

Re: [OMPI devel] MPI_Win_get_group

On 8/1/07, Jeff Squyres <jsquy...@cisco.com> wrote: > On Jul 31, 2007, at 6:43 PM, Lisandro Dalcin wrote: >> having to call XXX.Free() for every > > object i get from a call like XXX.Get_something() is really an > > unnecesary pain. > > Gotcha. > > But I

Re: [OMPI devel] [OMPI users] Possible Memcpy bug in MPI_Comm_split

On 8/16/07, George Bosilca wrote: > Well, finally someone discovered it :) I know about this problem for > quite a while now, it pop up during our own valgrind test of the > collective module in Open MPI. However, it never create any problems > in the applications, at least

[OMPI devel] MPI_GROUP_EMPTY and MPI_Group_free()

Dear all, As I see some activity on a related ticked, below some comments I sended to Bill Gropp some days ago about this subject. Bill did not write me back, I know he is really busy. Group operations are supposed to return new groups, so the used has to free the result. Additionally, the

[OMPI devel] valgrind warnings (uninited mem passed to syscall)

Dear all, I'm getting valgrind warnings related to syscalls with uninitialized memory (with release 1.2.4). Before providing more details and code reproducing the problem, I would like to know if there is any configure option I should take care of which enables extra memory initialization

[OMPI devel] some possible bugs after trying 1.2.6

Hi all, I've just downloaded and installed release 1.2.6. Additionally, I'm reimplementing from scratch my Python wrappers for MPI using some more advanded tools than manual C coding. Now, I do not try in any way of doing argument checking as I did before. Then I've ran al my unittest machinger.

[OMPI devel] Incomplete MPI-1 removal

All the symbols below are legacy MPI-1 stuff, then should go away, marked as deprecated, etc. $ grep "MPI_COMBINER_[HS].*_INTEGER" /home/devel/mpi/openmpi/4.0.1/include/mpi.h MPI_COMBINER_HVECTOR_INTEGER, MPI_COMBINER_HINDEXED_INTEGER, MPI_COMBINER_STRUCT_INTEGER, -- Lisan