<div dir="ltr"><div>Hi Hsin-Yu,<br>I mean neither of them<i>.<br></i></div><div>I thought you mentioned that it might be a glibc bug based on the reference you provided.<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></div><div>But in this case, all the error comes from inside the glibc.<br></div><div>So I think the problem here has nothing to do with the one you mentioned.<br><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 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">Hi Ye,<br>
<br>
Thanks a lot for the comment. Just for clarification: did you mean that<br>
the failure to generate debug symbols not libc bug, or the "==10233==<br>
Invalid write of size 8" warning not a libc bug?<br>
<br>
Thanks a lot,<br>
Hsin-Yu<br>
<span class=""><br>
On 05/05/2016 01:31 PM, Ye Luo wrote:<br>
> It doesn't seem to be a libc bug.<br>
> The call stack shows that in the subroutine check_quantity_dh ofyour<br>
> module mbdvdw,<br>
> the code failed in writing something into tgg_complex which seems to be<br>
> a variable belongs to your module.<br>
> Is this variable dynamically allocatable and not initialized?<br>
><br>
> Ye<br>
><br>
> ===================<br>
> Ye Luo, Ph.D.<br>
> Leadership Computing Facility<br>
> Argonne National Laboratory<br>
><br>
> 2016-05-05 12:14 GMT-05:00 Hsin-Yu Ko <<a href="mailto:hsinyu@princeton.edu">hsinyu@princeton.edu</a><br>
</span>> <mailto:<a href="mailto:hsinyu@princeton.edu">hsinyu@princeton.edu</a>>>:<br>
<div><div class="h5">><br>
> 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>
><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>
> > ==30486== Address 0x1037989f0 is 0 bytes after a block of size 1,728<br>
> > alloc'd<br>
> > ==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">hsinyu@princeton.edu</a> <mailto:<a href="mailto:hsinyu@princeton.edu">hsinyu@princeton.edu</a>><br>
</div></div><div><div class="h5">> > <mailto:<a href="mailto:hsinyu@princeton.edu">hsinyu@princeton.edu</a> <mailto:<a href="mailto:hsinyu@princeton.edu">hsinyu@princeton.edu</a>>>> wrote:<br>
> ><br>
> > Hi Thomas,<br>
> ><br>
> > Did you put -g in CFLAGS and LDFLAGS? Valgrind seems to<br>
> 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<br>
> on where<br>
> > > exactly the error is, and it doesn't give any important line<br>
> 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<br>
> 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<br>
> size 1,728<br>
> > > alloc'd<br>
> > > ==10233== at 0x1011814AB: malloc (in<br>
> > ><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<br>
> /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>
> > <a href="mailto:Q-e-developers@qe-forge.org">Q-e-developers@qe-forge.org</a><br>
> <mailto:<a href="mailto:Q-e-developers@qe-forge.org">Q-e-developers@qe-forge.org</a>><br>
</div></div>> <mailto:<a href="mailto:Q-e-developers@qe-forge.org">Q-e-developers@qe-forge.org</a><br>
<div class="HOEnZb"><div class="h5">> <mailto:<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>
> ><br>
> _______________________________________________<br>
> Q-e-developers mailing list<br>
> <a href="mailto:Q-e-developers@qe-forge.org">Q-e-developers@qe-forge.org</a> <mailto:<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>
><br>
><br>
><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>
_______________________________________________<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>
</div></div></blockquote></div><br></div>