suggestions for debugging code

[Randall Mackie]

Matthew,

Thanks - it took me the better part of the day yesterday to get the suppression
file so that it cut out most of the MPI stuff, and then I was able to eventually
zero in and find the offending bug.


Randy


Matthew Knepley wrote:
> On Tue, Jul 28, 2009 at 10:17 AM, Randall Mackie <rlmackie862 at gmail.com 
> <mailto:rlmackie862 at gmail.com>> wrote:
> 
>     I have run into a very difficult debugging problem. I have recently
>     made some
>     modifications to my PETSc code, to add some new features. When I
>     compiled the
>     code in debug mode (we are using the Intel compilers and mvapich on
>     Infiniband),
>     the code runs fine with any number of processes.
> 
>     When the code is compiled in optimize mode, it runs fine on, say, up
>     to 32 processes,
>     but not 64, bombing out someplace strange, with a Segmentation
>     Violation.
> 
>     I've tried using Valgrind, but you can't use it with PETSc and my
>     code compiled in
>     Debug mode because the code finishes successfully, and the other
>     problem I have with
> 
> 
> Sometimes valgrind will catch things even when code does not crash.
>  
> 
> 
>     Valgrind + mvapich is there are about a million messages spewed out,
>     making it
>     extremely difficult to see if there are really any issues in MY
>     code. I've thought
>     to have PETSc download and compile MPICH2, which I would hope would
>     produce less
>     output from Valgrind.
> 
> 
> In order to filter these out, you use a "suppressions file" for 
> valgrind. The manual has a
> good section on this and it should not be hard to wipre out most of 
> them. Satish designed
> one for our unit tests.
> 
>   Matt
>  
> 
> 
>     Anyone have any suggestions on how to debug this tricky situation?
>     Any suggestions
>     would be greatly appreciated.
> 
>     Randy
> 
> 
> 
> 
> -- 
> What most experimenters take for granted before they begin their 
> experiments is infinitely more interesting than any results to which 
> their experiments lead.
> -- Norbert Wiener