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