<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><br><br>On Fri, Apr 21, 2017 at 1:31 PM, Latham, Robert J. <<a href="mailto:robl@mcs.anl.gov">robl@mcs.anl.gov</a>> wrote:<br>><br>> On Fri, 2017-04-21 at 16:56 +0000, Sewall, Jason wrote:<br>> > Folks,<br>> ><br>> > I have been working on some code that does something akin to a<br>> > 'manual' implementation of gatherv with derived types. I've run into<br>> > a case where some requests never complete. I think it's a bug in<br>> > MPICH.:<br>><br>> good news, maybe?  <br>><br>> I can't reproduce this with today's MPICH .  I get some debug-logging<br>> warnings that you didn't free two of your types, but it doesn't hang on<br>> my laptop.  Those datatype-related allocations are the only valgrind<br>> error I see when I run "mpiexec -np 3 ./mpi-gather 256 256"<br>><br><br>I was able to reproduce it with d8e9213647e782b77a1e72fde6a7638198ac3be5 on Mac, but only when I ran with MPIR_CVAR_NOLOCAL=1.<br><br><div>Jeff</div><div> <br>><br>> Is it possible a 256 by 256 grids could overflow an integer anywhere?<br>> I think master has some integer overflow fixes in the gather path that<br>> might not have made it into an MPICH release.  Aside from that, I'd<br>> have to dig through the history to figure out what might be different.<br>><br>> ==rob<br>><br>> ><br>> > My minimal code example is still ~300 lines long, so I've stuck it,<br>> > as well as a run script and some example output here:<br>> ><br>> > <a href="https://gist.github.com/jasonsewall/0d1fb12a93e157795786e560733cbf0c">https://gist.github.com/jasonsewall/0d1fb12a93e157795786e560733cbf0c</a><br>> ><br>> > I'm new to this list, so if there's a better place/practice for<br>> > sharing code, please let me know.<br>> ><br>> > The code mimics a decomposition of a multi-field grid in 2<br>> > dimensions. Each grid has a halo region allocated, and this gather is<br>> > only interested in transmitting the interior of each grid. <br>> ><br>> > The conditions, as far as I can tell, are related to:<br>> ><br>> > 1. nranks > 2<br>> > 2. 'larger' messages: I haven't fully bisected it, but 256x128 grids<br>> > work, and 256x256 don't.<br>> > 3. Having halos. With the global integer halow = 2, the strides for<br>> > the grids (and the resulting hvector derived types) exceed the<br>> > lengths, and that seems to be important; if you set halow = 0 and<br>> > run, it completes, independent of the other factors. <br>> ><br>> > The test program uses Waitsome to figure out which requests are<br>> > completing, and it looks like rank 0 fails to complete a recv from<br>> > rank 2, despite rank 2 completing its send.  <br>> ><br>> > You can fiddle with the hacky 'mask' parameter to have a subset of<br>> > the ranks send (line 326). -1ULL means all ranks are allowed in, but<br>> > you get interesting results with 6ULL, which has just ranks 1 and 2<br>> > participate in sending, but rank 0 still hangs on the recv from rank<br>> > 2. (Obviously the correctness test will fail here, since it expects<br>> > results from all ranks).<br>> ><br>> > I discovered this on Intel MPI, and thanks to my colleague Jeff<br>> > Hammond's analysis, was able to reproduce the behavior on MPICH 3.2.<br>> > OpenMPI 2.1.0 successfully completes every case I have tried.<br>> ><br>> > The obvious caveat here is that there could very well be a bug in how<br>> > I'm using the derived datatypes, but I have tried to carefully check<br>> > that I'm not trashing random memory. Things seem correct.<br>> ><br>> > Please let me know what I can do help pinpoint the problem. I'm not<br>> > familiar with the implementation details of any MPI libraries.<br>> ><br>> > Cheers,<br>> > Jason<br>> >  <br>> > _______________________________________________<br>> > discuss mailing list     <a href="mailto:discuss@mpich.org">discuss@mpich.org</a><br>> > To manage subscription options or unsubscribe:<br>> > <a href="https://lists.mpich.org/mailman/listinfo/discuss">https://lists.mpich.org/mailman/listinfo/discuss</a><br>> _______________________________________________<br>> discuss mailing list     <a href="mailto:discuss@mpich.org">discuss@mpich.org</a><br>> To manage subscription options or unsubscribe:<br>> <a href="https://lists.mpich.org/mailman/listinfo/discuss">https://lists.mpich.org/mailman/listinfo/discuss</a><br><br><br><br><br>--<br>Jeff Hammond<br><a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/">http://jeffhammond.github.io/</a></div></div>