suggestions for debugging code

Randall Mackie rlmackie862 at gmail.com
Wed Jul 29 14:09:32 CDT 2009


That looks interesting. Has anyone tried Totalview or PGDBG?

Randy

Yaakoub El Khamra wrote:
> 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


More information about the petsc-users mailing list