Barry Smith <bsm...@mcs.anl.gov> writes: >> On Oct 18, 2017, at 3:10 PM, Lisandro Dalcin <dalc...@gmail.com> wrote: >> >> On 18 October 2017 at 22:36, Satish Balay <ba...@mcs.anl.gov> wrote: >>> On Wed, 18 Oct 2017, Lisandro Dalcin wrote: >>> >>> Alternate is to remove/increase the timout. It doesn't work for some >>> builds anyway [esp valgrind runs] >>> >>> This feature relies on sending 'kill' message to the process it >>> started - i.e mpiexec. But some mpiexecs when killed - don't kill the >>> child processes cleanly] >>> >>> $ git diff |cat >>> diff --git a/bin/maint/buildtest b/bin/maint/buildtest >>> index 31b5a3a028..e4bbf96db8 100755 >>> --- a/bin/maint/buildtest >>> +++ b/bin/maint/buildtest >>> @@ -104,7 +104,7 @@ if ( $? ) then >>> else >>> set VALGRIND=`echo MPIEXEC="${PETSC_DIR}/bin/petscmpiexec -valgrind"` >>> setenv PETSCVALGRIND_OPTIONS >>> "--suppressions=${PETSC_DIR}/bin/maint/petsc-val.supp" >>> - set TIMEOUT=720 >>> + set TIMEOUT=7200 >>> endif >>> >> >> No, please don't! Be green, Satish! >> >> What's the point of running a 3D problem under valgrind for 2 hours? > > Find memory corruption bugs that won't be found otherwise?
So use three elements and two time steps. > But note that the original test problems should be taking only a short > time so even with valgrind should not take 2 hours. Yes.