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