suggestions for debugging code

Yaakoub El Khamra yaakoub at tacc.utexas.edu
Wed Jul 29 14:19:00 CDT 2009


I used totalview heavily, it has memory debugging but at the time it
was only on a single core. That restriction might have been lifted, I
am not sure.

Regards
Yaakoub El Khamra




On Wed, Jul 29, 2009 at 2:09 PM, Randall Mackie<rlmackie862 at gmail.com> wrote:
> 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