suggestions for debugging code

[Yaakoub El Khamra]

Just my 2c, but if you might want to check out DDT, it is a parallel
debugger with built-in memory checking. If you have a teragrid
account, you can probably use it on ranger or lonestar. It is
licensed, but until the eclipse PTP project comes around with memory
checking, it is an alternative.

Regards
Yaakoub El Khamra




On Wed, Jul 29, 2009 at 11:36 AM, Randall Mackie<rlmackie862 at gmail.com> wrote:
> 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
>