[Q-e-developers] Using Valgrind and GDB with QE
Ye Luo
xw111luoye at gmail.com
Thu May 5 23:38:26 CEST 2016
It looks correct but I noticed you are using a Mac which I have zero
knowledge about it.
I hope a Linux box will make your life easier ;)
Ciao,
Ye
===================
Ye Luo, Ph.D.
Leadership Computing Facility
Argonne National Laboratory
2016-05-05 16:21 GMT-05:00 Thomas Markovich <thomasmarkovich at gmail.com>:
> Hi Ye,
>
> Thank you for your response. I did 1 and my compile statement looks like:
> mpif90 -Og -g -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
>
> my backtrace in GDB looks like:
> (gdb) where
> #0 0x0000000100267d24 in __mbdvdw_module_MOD_mbdvdw_compute_tdip ()
> #1 0x000000010026a392 in __mbdvdw_module_MOD_mbdvdw_compute_tlr ()
> #2 0x000000010026ac7f in __mbdvdw_module_MOD_mbdvdw_compute_tlr_complex ()
> #3 0x000000010026c425 in __mbdvdw_module_MOD_mbdvdw_tgg_complex ()
> #4 0x0000000100288e0a in __mbdvdw_module_MOD_mbdvdw_check_quantity_dh ()
> #5 0x0000000000000000 in ?? ()
>
> My GDB is configured as:
>
> ▶ gdb
> GNU gdb (GDB) 7.11
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-apple-darwin14.5.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word".
> (gdb) show configuration
> This GDB was configured as follows:
> configure --host=x86_64-apple-darwin14.5.0
> --target=x86_64-apple-darwin14.5.0
> --with-auto-load-dir=:${prefix}/share/auto-load
> --with-auto-load-safe-path=:${prefix}/share/auto-load
> --with-expat
> --with-gdb-datadir=/usr/local/Cellar/gdb/7.11/share/gdb
> (relocatable)
> --with-jit-reader-dir=/usr/local/Cellar/gdb/7.11/lib/gdb
> (relocatable)
> --without-libunwind-ia64
> --without-lzma
>
> --with-python=/System/Library/Frameworks/Python.framework/Versions/2.7
> --without-guile
>
> --with-separate-debug-dir=/usr/local/Cellar/gdb/7.11/lib/debug
> (relocatable)
> --without-babeltrace
>
> ("Relocatable" means the directory can be moved with the GDB installation
> tree, and GDB will still find it.)
>
> Does that possibly match yours?
>
> I'll take care of 2 tonight.
>
> Thanks!
>
> Thomas
>
> On Thu, May 5, 2016 at 3:31 PM, Ye Luo <xw111luoye at gmail.com> wrote:
>
>> Hi Thomas,
>>
>> I just checked my local QE build with gcc 4.8.4 and gdb 7.7.1. And I can
>> see the line info.
>> Here is the configuration in my make.sys and only -g is needed.
>>
>> CFLAGS = -O3 $(DFLAGS) $(IFLAGS)
>> F90FLAGS = $(FFLAGS) -x f95-cpp-input $(FDFLAGS) $(IFLAGS)
>> $(MODFLAGS)
>> FFLAGS = -O3 -g
>>
>> I'd like you to check two things:
>> 1) How you modified the makefile to add your mbdvdw module source file.
>> Are all the flags passed to it when it is compiled?
>> You can check this remove the .o and .mod file associated to the module
>> and rerun make. Check if -g appears in the compilation.
>> 2) Try another computer.. I have no better ideas..
>>
>> Ye
>>
>> My call tree:
>> #0 simpson (mesh=<optimized out>, func=..., rab=..., asum=0) at
>> simpsn.f90:39
>> #1 0x000000000057f345 in atomic_rho (rhoa=..., nspina=1) at
>> atomic_rho.f90:95
>> #2 0x00000000005052a4 in potinit () at potinit.f90:123
>> #3 0x00000000004b64e3 in init_run () at init_run.f90:99
>> #4 0x0000000000407219 in run_pwscf (exit_status=0) at run_pwscf.f90:72
>> #5 0x00000000004070a5 in pwscf () at pwscf.f90:30
>> #6 main (argc=argc at entry=3, argv=0x7fffffffdf98) at pwscf.f90:14
>> #7 0x00007ffff69b6ec5 in __libc_start_main (main=0x407050 <main>,
>> argc=3, argv=0x7fffffffdbd8, init=<optimized out>, fini=<optimized out>,
>> rtld_fini=<optimized out>, stack_end=0x7fffffffdbc8)
>> at libc-start.c:287
>> #8 0x00000000004070ef in _start ()
>>
>>
>> ===================
>> Ye Luo, Ph.D.
>> Leadership Computing Facility
>> Argonne National Laboratory
>>
>> 2016-05-05 13:39 GMT-05:00 Thomas Markovich <thomasmarkovich at gmail.com>:
>>
>>> Hi Ye,
>>>
>>> Thank you for your response! I just ran GDB to see if it was an issue
>>> with valgrind alone, but I'm getting similar behaviour:
>>>
>>> (gdb) where
>>> #0 0x0000000100267d24 in __mbdvdw_module_MOD_mbdvdw_compute_tdip ()
>>> #1 0x000000010026a392 in __mbdvdw_module_MOD_mbdvdw_compute_tlr ()
>>> #2 0x000000010026ac7f in __mbdvdw_module_MOD_mbdvdw_compute_tlr_complex
>>> ()
>>> #3 0x000000010026c425 in __mbdvdw_module_MOD_mbdvdw_tgg_complex ()
>>> #4 0x0000000100288e0a in __mbdvdw_module_MOD_mbdvdw_check_quantity_dh ()
>>> #5 0x0000000000000000 in ?? ()
>>>
>>> (gdb) info symbol 0x0000000100288e0a
>>> __mbdvdw_module_MOD_mbdvdw_check_quantity_dh + 4475 in section .text of
>>> /Users/tmarkovich/Dropbox (Aspuru-Guzik
>>> Lab)/Projects/MBD/mbd_espresso/PW/src/pw.x
>>> (gdb) info symbol 0x0000000100267d24
>>> __mbdvdw_module_MOD_mbdvdw_compute_tdip + 62 in section .text of
>>> /Users/tmarkovich/Dropbox (Aspuru-Guzik
>>> Lab)/Projects/MBD/mbd_espresso/PW/src/pw.x
>>>
>>> Note, this was done with GDB 7.11. I have pasted my make.sys file below.
>>>
>>> Best,
>>> Thomas
>>>
>>> # make.sys. Generated from make.sys.in by configure.
>>>
>>> # compilation rules
>>>
>>> .SUFFIXES :
>>> .SUFFIXES : .o .c .f .f90
>>>
>>> # most fortran compilers can directly preprocess c-like directives: use
>>> # $(MPIF90) $(F90FLAGS) -c $<
>>> # if explicit preprocessing by the C preprocessor is needed, use:
>>> # $(CPP) $(CPPFLAGS) $< -o $*.F90
>>> # $(MPIF90) $(F90FLAGS) -c $*.F90 -o $*.o
>>> # remember the tabulator in the first column !!!
>>>
>>> .f90.o:
>>> $(MPIF90) $(F90FLAGS) -c $<
>>>
>>> # .f.o and .c.o: do not modify
>>>
>>> .f.o:
>>> $(F77) $(FFLAGS) -c $<
>>>
>>> .c.o:
>>> $(CC) $(CFLAGS) -c $<
>>>
>>>
>>>
>>> # topdir for linking espresso libs with plugins
>>> TOPDIR = /Users/tmarkovich/Dropbox (Aspuru-Guzik
>>> Lab)/Projects/MBD/mbd_espresso
>>>
>>> # DFLAGS = precompilation options (possible arguments to -D and -U)
>>> # used by the C compiler and preprocessor
>>> # FDFLAGS = as DFLAGS, for the f90 compiler
>>> # See include/defs.h.README for a list of options and their meaning
>>> # With the exception of IBM xlf, FDFLAGS = $(DFLAGS)
>>> # For IBM xlf, FDFLAGS is the same as DFLAGS with separating commas
>>>
>>> # MANUAL_DFLAGS = additional precompilation option(s), if desired
>>> # You may use this instead of tweaking DFLAGS and
>>> FDFLAGS
>>> # BEWARE: will not work for IBM xlf! Manually edit
>>> FDFLAGS
>>> MANUAL_DFLAGS =
>>> DFLAGS = -D__GFORTRAN -D__STD_F95 -D__FFTW -D__MPI -D__PARA
>>> -D__SCALAPACK -D__OPENMP $(MANUAL_DFLAGS)
>>> FDFLAGS = $(DFLAGS) $(MANUAL_DFLAGS)
>>>
>>> # IFLAGS = how to locate directories where files to be included are
>>> # In most cases, IFLAGS = -I../include
>>>
>>> IFLAGS = -I../include
>>>
>>> # MOD_FLAGS = flag used by f90 compiler to locate modules
>>> # Each Makefile defines the list of needed modules in MODFLAGS
>>>
>>> MOD_FLAG = -I
>>>
>>> # Compilers: fortran-90, fortran-77, C
>>> # If a parallel compilation is desired, MPIF90 should be a fortran-90
>>> # compiler that produces executables for parallel execution using MPI
>>> # (such as for instance mpif90, mpf90, mpxlf90,...);
>>> # otherwise, an ordinary fortran-90 compiler (f90, g95, xlf90, ifort,...)
>>> # If you have a parallel machine but no suitable candidate for MPIF90,
>>> # try to specify the directory containing "mpif.h" in IFLAGS
>>> # and to specify the location of MPI libraries in MPI_LIBS
>>>
>>> MPIF90 = mpif90
>>> #F90 = gfortran
>>> CC = gcc-5
>>> F77 = gfortran
>>>
>>> # C preprocessor and preprocessing flags - for explicit preprocessing,
>>> # if needed (see the compilation rules above)
>>> # preprocessing flags must include DFLAGS and IFLAGS
>>>
>>> CPP = cpp-5 -ansi -C
>>> CPPFLAGS = $(DFLAGS) $(IFLAGS)
>>>
>>> # compiler flags: C, F90, F77
>>> # C flags must include DFLAGS and IFLAGS
>>> # F90 flags must include MODFLAGS, IFLAGS, and FDFLAGS with appropriate
>>> syntax
>>>
>>> CFLAGS = -Og -g $(DFLAGS) $(IFLAGS)
>>> F90FLAGS = $(FFLAGS) -x f95-cpp-input -fopenmp $(FDFLAGS)
>>> $(IFLAGS) $(MODFLAGS)
>>> FFLAGS = -Og -g -fopenmp -Wall -Wextra -Warray-temporaries
>>> -Wconversion -fbacktrace -ffree-line-length-0 -finit-real=nan
>>> -ffpe-trap=zero,invalid,zero,overflow
>>>
>>> # compiler flags without optimization for fortran-77
>>> # the latter is NEEDED to properly compile dlamch.f, used by lapack
>>>
>>> FFLAGS_NOOPT = -O0 -g
>>>
>>> # compiler flag needed by some compilers when the main is not fortran
>>> # Currently used for Yambo
>>>
>>> FFLAGS_NOMAIN =
>>>
>>> # Linker, linker-specific flags (if any)
>>> # Typically LD coincides with F90 or MPIF90, LD_LIBS is empty
>>>
>>> LD = mpif90
>>> LDFLAGS = -g -pthread -fopenmp
>>> LD_LIBS =
>>>
>>> # External Libraries (if any) : blas, lapack, fft, MPI
>>>
>>> # If you have nothing better, use the local copy :
>>> # BLAS_LIBS = /your/path/to/espresso/BLAS/blas.a
>>> # BLAS_LIBS_SWITCH = internal
>>>
>>> BLAS_LIBS = -lblas
>>> BLAS_LIBS_SWITCH = external
>>>
>>> # If you have nothing better, use the local copy :
>>> # LAPACK_LIBS = /your/path/to/espresso/lapack-3.2/lapack.a
>>> # LAPACK_LIBS_SWITCH = internal
>>> # For IBM machines with essl (-D__ESSL): load essl BEFORE lapack !
>>> # remember that LAPACK_LIBS precedes BLAS_LIBS in loading order
>>>
>>> LAPACK_LIBS = -llapack -lblas
>>> LAPACK_LIBS_SWITCH = external
>>>
>>> ELPA_LIBS_SWITCH = disabled
>>> SCALAPACK_LIBS = -lscalapack
>>>
>>> # nothing needed here if the the internal copy of FFTW is compiled
>>> # (needs -D__FFTW in DFLAGS)
>>>
>>> FFT_LIBS =
>>>
>>> # For parallel execution, the correct path to MPI libraries must
>>> # be specified in MPI_LIBS (except for IBM if you use mpxlf)
>>>
>>> MPI_LIBS =
>>>
>>> # IBM-specific: MASS libraries, if available and if -D__MASS is defined
>>> in FDFLAGS
>>>
>>> MASS_LIBS =
>>>
>>> # ar command and flags - for most architectures: AR = ar, ARFLAGS = ruv
>>>
>>> AR = ar
>>> ARFLAGS = ruv
>>>
>>> # ranlib command. If ranlib is not needed (it isn't in most cases) use
>>> # RANLIB = echo
>>>
>>> RANLIB = ranlib -c
>>>
>>> # all internal and external libraries - do not modify
>>>
>>> FLIB_TARGETS = all
>>>
>>> LIBOBJS = ../flib/ptools.a ../flib/flib.a ../clib/clib.a
>>> ../iotk/src/libiotk.a
>>> LIBS = $(SCALAPACK_LIBS) $(LAPACK_LIBS) $(FFT_LIBS)
>>> $(BLAS_LIBS) $(MPI_LIBS) $(MASS_LIBS) $(LD_LIBS)
>>>
>>> # wget or curl - useful to download from network
>>> WGET = wget -O
>>>
>>>
>>>
>>>
>>> On Thu, May 5, 2016 at 2:29 PM, Ye Luo <xw111luoye at gmail.com> wrote:
>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>
> _______________________________________________
> 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/72597d25/attachment.html>
More information about the developers
mailing list