From 89a7204b5cc355432e0fddd01a54f7a1975b49e0 Mon Sep 17 00:00:00 2001 From: Augustin Degomme Date: Wed, 10 Jul 2019 14:59:57 +0200 Subject: [PATCH] Try to avoid rare bug on one ci node. A guess is that the win_lock call by a process may be finishing the comms posted by the raccumulate call from the other process. And this would mean having max(0,undefined) as a result if memory is not initialized before win_lock_all. I didn't find anything saying lock_all should be blocking/collective, so I'm not modifying it for so little. Other guess: something's rotten with locks, as I think we don't check properly for them before posting rma calls. --- teshsuite/smpi/mpich3-test/rma/racc_local_comp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/teshsuite/smpi/mpich3-test/rma/racc_local_comp.c b/teshsuite/smpi/mpich3-test/rma/racc_local_comp.c index a86c766d1a..35c228a0df 100644 --- a/teshsuite/smpi/mpich3-test/rma/racc_local_comp.c +++ b/teshsuite/smpi/mpich3-test/rma/racc_local_comp.c @@ -33,10 +33,9 @@ int main(int argc, char *argv[]) MPI_Alloc_mem(MAX_SIZE * sizeof(int), MPI_INFO_NULL, &winbuf); MPI_Win_create(winbuf, MAX_SIZE * sizeof(int), sizeof(int), MPI_INFO_NULL, MPI_COMM_WORLD, &window); - - MPI_Win_lock_all(0, window); buf[0] = 0; winbuf[0]=0; + MPI_Win_lock_all(0, window); /* Test Raccumulate local completion with small data. * Small data is always copied to header packet as immediate data. */ if (rank == 1) { -- 2.20.1