[Q-e-developers] Using Valgrind and GDB with QE
Ye Luo
xw111luoye at gmail.com
Thu May 5 20:29:04 CEST 2016
Hi Thomas,
Sorry about that I didn't catch the exact point you asked.
I just want to add a general comment.
In my experience, -g should be sufficient for your purpose.
All the profiling or debugging tools I use, including DDT, gdb, HPCtoolkit,
vtune only requires the code compiled with -g and can provide information
about call stack and line specific details.
Ye
===================
Ye Luo, Ph.D.
Leadership Computing Facility
Argonne National Laboratory
2016-05-05 12:40 GMT-05:00 Thomas Markovich <thomasmarkovich at gmail.com>:
> Hi Ye,
>
> Thank you for your comment! __mbdvdw_module_MOD_mbdvdw_tgg_complex is a
> subroutine, not an array. It appears that the invalid write is happening
> somewhere inside of tgg_complex, presumably the variable is stored at 0x103131248.
> I was hoping that when compiled with debug symbols, valgrind would be able
> to tell me the line number of tgg_complex.
>
> Best,
> Thomas
>
> On Thu, May 5, 2016 at 1:31 PM, Ye Luo <xw111luoye at gmail.com> wrote:
>
>> It doesn't seem to be a libc bug.
>> The call stack shows that in the subroutine check_quantity_dh of your
>> module mbdvdw,
>> the code failed in writing something into tgg_complex which seems to be a
>> variable belongs to your module.
>> Is this variable dynamically allocatable and not initialized?
>>
>> Ye
>>
>> ===================
>> Ye Luo, Ph.D.
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>> 2016-05-05 12:14 GMT-05:00 Hsin-Yu Ko <hsinyu at princeton.edu>:
>>
>>> Thomas,
>>>
>>> That is interesting. What you are seeing seems to be a libc bug [1]. I
>>> have encountered something similar last month. I fixed the problem on my
>>> machine by recompiling glibc with debug features enabled (I am not sure
>>> how useful gentoo documentation is but I put the reference here just in
>>> case [2]). I think removing -pg may be a quick fix according to [1].
>>>
>>> Best,
>>> Hsin-Yu
>>>
>>> [1] http://valgrind-users.narkive.com/MPnV7HOw/gcc-pg-valgrind-errors
>>> [2] https://wiki.gentoo.org/wiki/Debugging
>>>
>>> On 05/05/2016 12:34 PM, Thomas Markovich wrote:
>>> > Hsin-Yu,
>>> >
>>> > Thank you for the suggestion!
>>> >
>>> > I had -g in LDFLAGS:
>>> > LDFLAGS = -g -pthread -fopenmp
>>> >
>>> > but nothing equivalent in CFLAGS, which was defined as:
>>> > CFLAGS = -O3 $(DFLAGS) $(IFLAGS)
>>> >
>>> > I have since gone ahead and changed CFLAGS to
>>> > CFLAGS = -Og -g $(DFLAGS) $(IFLAGS)
>>> >
>>> > The resulting fortran compile statements look something like:
>>> > mpif90 -Og -g -pg -fopenmp -Wall -Wextra -Warray-temporaries
>>> > -Wconversion -fbacktrace -ffree-line-length-0 -finit-real=nan
>>> > -ffpe-trap=zero,invalid,zero,overflow -x f95-cpp-input -fopenmp
>>> > -D__GFORTRAN -D__STD_F95 -D__FFTW -D__MPI -D__PARA -D__SCALAPACK
>>> > -D__OPENMP -I../include -I../iotk/src -I../ELPA/src -I. -c mbdvdw.f90
>>> >
>>> > and reran valgrind. It gave the following output:
>>> >
>>> > ==30486== Invalid write of size 8
>>> > ==30486== at 0x1002735ED: __mbdvdw_module_MOD_mbdvdw_tgg_complex (in
>>> > /Users/tmarkovich/bin/pw.x)
>>> > ==30486== by 0x100290F58:
>>> > __mbdvdw_module_MOD_mbdvdw_check_quantity_dh (in
>>> /Users/tmarkovich/bin/pw.x)
>>> > ==30486== Address 0x1037989f0 is 0 bytes after a block of size 1,728
>>> > alloc'd
>>> > ==30486== at 0x10092B4AB: malloc (in
>>> >
>>> /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
>>> > ==30486== by 0x10028FEE2:
>>> > __mbdvdw_module_MOD_mbdvdw_check_quantity_dh (in
>>> /Users/tmarkovich/bin/pw.x)
>>> > ==30486== by 0x1001D4567: v_of_rho_ (in /Users/tmarkovich/bin/pw.x)
>>> > ==30486== by 0x10007C0BE: electrons_scf_ (in
>>> /Users/tmarkovich/bin/pw.x)
>>> > ==30486== by 0x10007D385: electrons_ (in /Users/tmarkovich/bin/pw.x)
>>> > ==30486== by 0x10018B30B: run_pwscf_ (in /Users/tmarkovich/bin/pw.x)
>>> > ==30486== by 0x100001157: MAIN__ (pwscf.f90:30)
>>> > ==30486== by 0x1004EC496: main (pwscf.f90:14)
>>> >
>>> > This appears to not have changed much.
>>> >
>>> > Best,
>>> > Thomas
>>> >
>>> > On Thu, May 5, 2016 at 10:15 AM, Hsin-Yu Ko <hsinyu at princeton.edu
>>> > <mailto:hsinyu at princeton.edu>> wrote:
>>> >
>>> > Hi Thomas,
>>> >
>>> > Did you put -g in CFLAGS and LDFLAGS? Valgrind seems to recognize
>>> some
>>> > lines inside MAIN__ while failing to find the linked ones.
>>> >
>>> > Best,
>>> > Hsin-Yu
>>> >
>>> > On 05/05/2016 09:48 AM, Thomas Markovich wrote:
>>> > > Hi,
>>> > >
>>> > > I'm preparing to push my module that implements the Many Body
>>> > Dispersion
>>> > > van der Waals correction, and all associated forces. As a last
>>> > thing, I
>>> > > ran my code through valgrind, and it seems to have popped up a
>>> > couple of
>>> > > remaining things that I would like to fix before release[1].
>>> > > Unfortunately, the valgrind output below is less than clear on
>>> where
>>> > > exactly the error is, and it doesn't give any important line
>>> numbers.
>>> > > Beyond this, addr2line gives thoroughly unhelpful output:
>>> > > ▶ gaddr2line -e pw.x 0x100520518
>>> > > ??:0.
>>> > >
>>> > > I have compiled QE given the following flags with gfortran 4.9:
>>> > > FFLAGS = -Og -g -pg -fopenmp -fbacktrace -fcheck=all
>>> > > -finit-real=nan -ffpe-trap=zero,invalid,zero,overflow
>>> > >
>>> > > Is there any way to compile QE such that it generates all the
>>> > debugging
>>> > > symbols, so that I can get more readable and informative output
>>> from
>>> > > valgrind? I thought all I needed was the -g flag, but it appears
>>> > that I
>>> > > might need more?
>>> > >
>>> > > Best,
>>> > > Thomas Markovich
>>> > >
>>> > > [1]
>>> > > ==10233== Invalid write of size 8
>>> > > ==10233== at 0x100520518:
>>> > __mbdvdw_module_MOD_mbdvdw_tgg_complex (in
>>> > > /Users/tmarkovich/bin/pw.x)
>>> > > ==10233== by 0x100555A88:
>>> > > __mbdvdw_module_MOD_mbdvdw_check_quantity_dh (in
>>> > /Users/tmarkovich/bin/pw.x)
>>> > > ==10233== Address 0x103131248 is 8 bytes after a block of size
>>> 1,728
>>> > > alloc'd
>>> > > ==10233== at 0x1011814AB: malloc (in
>>> > >
>>> >
>>> /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
>>> > > ==10233== by 0x1005547B0:
>>> > > __mbdvdw_module_MOD_mbdvdw_check_quantity_dh (in
>>> > /Users/tmarkovich/bin/pw.x)
>>> > > ==10233== by 0x1003D56E4: v_of_rho_ (in
>>> /Users/tmarkovich/bin/pw.x)
>>> > > ==10233== by 0x1000F540B: electrons_scf_ (in
>>> > /Users/tmarkovich/bin/pw.x)
>>> > > ==10233== by 0x1000F6E18: electrons_ (in
>>> > /Users/tmarkovich/bin/pw.x)
>>> > > ==10233== by 0x10032AA28: run_pwscf_ (in
>>> > /Users/tmarkovich/bin/pw.x)
>>> > > ==10233== by 0x1000010BB: MAIN__ (pwscf.f90:30)
>>> > > ==10233== by 0x100B67C1F: main (pwscf.f90:14)
>>> > _______________________________________________
>>> > Q-e-developers mailing list
>>> > Q-e-developers at qe-forge.org <mailto:Q-e-developers at qe-forge.org>
>>> > http://qe-forge.org/mailman/listinfo/q-e-developers
>>> >
>>> >
>>> _______________________________________________
>>> Q-e-developers mailing list
>>> Q-e-developers at qe-forge.org
>>> http://qe-forge.org/mailman/listinfo/q-e-developers
>>>
>>
>>
>> _______________________________________________
>> Q-e-developers mailing list
>> Q-e-developers at qe-forge.org
>> http://qe-forge.org/mailman/listinfo/q-e-developers
>>
>>
>
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> http://qe-forge.org/mailman/listinfo/q-e-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20160505/fac1ecc1/attachment.html>
More information about the developers
mailing list