<div dir="ltr">valgrind on Edison does seem to give a lot of false positives.  The line number are accurate (not always the case).  "assert" triggers it, as does SETERRQ.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, 2015 at 8:51 AM, Mark Adams <span dir="ltr"><<a href="mailto:mfadams@lbl.gov" target="_blank">mfadams@lbl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I ran an 8 processor job on Edison of a small code for a short run (just a linear solve) and got 37 Mb of output!<br><br></div>Here is a 'Petsc' grep.<br><br></div>Perhaps we should build an ignore file for things that we believe is a false positive.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 3, 2015 at 11:55 AM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  I am more optimistic about valgrind than Mark. I first try valgrind and if that fails to be helpful then use the debugger. valgrind has the advantage that it finds the FIRST place that something is wrong, while in the debugger it is kind of late at the crash.<br>
<br>
  Valgrind should not be noisy, if it is then the applications/libraries should be cleaned up so that they are valgrind clean and then valgrind is useful.<br>
<span><font color="#888888"><br>
  Barry<br>
</font></span><div><div><br>
<br>
<br>
> On Nov 3, 2015, at 7:47 AM, Mark Adams <<a href="mailto:mfadams@lbl.gov" target="_blank">mfadams@lbl.gov</a>> wrote:<br>
><br>
> BTW, I think that our advice for segv is use a debugger.  DDT or Totalview, and gdb if need be, will get you right to the source code and will get 90% of bugs diagnosed.  Valgrind is noisy and cumbersome to use but can diagnose 90% of the other 10%.<br>
><br>
> On Tue, Nov 3, 2015 at 7:32 AM, Denis Davydov <<a href="mailto:davydden@gmail.com" target="_blank">davydden@gmail.com</a>> wrote:<br>
> Hi Jose,<br>
><br>
> > On 3 Nov 2015, at 12:20, Jose E. Roman <<a href="mailto:jroman@dsic.upv.es" target="_blank">jroman@dsic.upv.es</a>> wrote:<br>
> ><br>
> > I am answering the SLEPc-related questions:<br>
> > - Having different number of iterations when changing the number of processes is normal.<br>
> the change in iterations i mentioned are for different preconditioners, but the same number of MPI processes.<br>
><br>
><br>
> > - Yes, if you do not destroy the EPS solver, then the preconditioner would be reused.<br>
> ><br>
> > Regarding the segmentation fault, I have no clue. Not sure if this is related to GAMG or not. Maybe running under valgrind could provide more information.<br>
> will try that.<br>
><br>
> Denis.<br>
><br>
<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>