Dear Jeff, I have very interesting news. I recompiled OpenMPI 1.4.4 enabling the memchecker.
Now the warning on strcmp is disappeared also without buffers initializations using memset! So the warning is a false positive? My simple code is safe? Thanks. 2012/1/28 Jeff Squyres <jsquy...@cisco.com> > On Jan 28, 2012, at 5:22 AM, Gabriele Fatigati wrote: > > > I had the same idea so my simple code I have already done calloc and > memset .. > > > > The same warning still appear using strncmp that should exclude > uninitialized bytes on hostnam_recv_buf :( > > Bummer. > > > My apologize for being so insistent, but I would understand if there is > some bug in MPI_Allgather, strcmp or Valgrind itself. > > Understood. > > I still think that MPI_Allgather will exactly send the bytes starting at > the buffer you specify, regardless of whether they include \0 or not. > > I was unable to replicate the valgrind warning on my systems. A few more > things to try: > > 1. Are you using the latest version of Valgrind? > > 2. (I should have asked this before - sorry!) Are you using InfiniBand to > transmit the data across your network? If so, Valgrind might not have > visibility on the receive buffers being filled because IB, by its nature, > uses OS bypass to fill in receive buffers. Meaning: Valgrind won't "see" > the receive buffers getting filled, and therefore will think that they are > uninitialized. If you re-run your experiment with TCP and/or shared memory > (like I did), you won't see the Valgrind uninitialized warnings. > > To avoid these OS-bypass issues, you might try installing Open MPI with > --with-valgrind=DIR (DIR = directory where Valgrind is installed -- we need > valgrind.h, IIRC). What this does is allow Open MPI to use Valgrind's > external tools API to say "don't worry Valgrind, the entire contents of > this buffer are initialized" in cases exactly like this. > > There is a performance cost to using Valgrind integration, though. So > don't make this your production copy of Open MPI. > > 3. Do a for loop accessing each position of the buffer *before* you send > it. Not just up to the \0, but traverse the *entire length* of the buffer > and do some meaningless action with each byte. See if Valgrind complains. > If it doesn't, you know for certain that the entire source buffer is not > the origin of the warning. > > 4. Similarly, do a loop accessing each position of the received buffer. > You can have Valgrind attach a debugger when it runs into issues; with > that, you can see exactly which position Valgrind thinks is uninitialized. > Compare the value that was sent to the value that was received and ensure > that they are the same. > > Hope that helps! > > -- > Jeff Squyres > jsquy...@cisco.com > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users > -- Ing. Gabriele Fatigati HPC specialist SuperComputing Applications and Innovation Department Via Magnanelli 6/3, Casalecchio di Reno (BO) Italy www.cineca.it Tel: +39 051 6171722 g.fatigati [AT] cineca.it
