Did you run ? valgrind --trace-malloc=yes a.out if yes, then malloc() and free() are traced. hex numbers are the results of malloc or arguments of free, so these are pointers to the heap (e.g. data). these are not pointers to instructions and hence cannot be converted to source code/line number.
what if you ? valgrind --leak-check=full ... do you get source filename and line numbers ? see below for a sample of what i get Cheers, Gilles 10 bytes in 1 blocks are definitely lost in loss record 11 of 186 ==2379== at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==2379== by 0x5479AB9: strdup (in /usr/lib64/libc-2.17.so) ==2379== by 0x5B1D74F: mca_base_var_enum_create_flag (mca_base_var_enum.c:274) ==2379== by 0x5B378EC: mca_btl_base_register (btl_base_frame.c:149) ==2379== by 0x5B215BD: mca_base_framework_register (mca_base_framework.c:120) ==2379== by 0x5B2164F: mca_base_framework_open (mca_base_framework.c:146) ==2379== by 0x4F1390A: mca_bml_base_open (bml_base_frame.c:117) ==2379== by 0x5B216FC: mca_base_framework_open (mca_base_framework.c:174) ==2379== by 0x4E8F8EA: ompi_mpi_init (ompi_mpi_init.c:604) ==2379== by 0x4ECD472: PMPI_Init (pinit.c:66) ==2379== by 0x4008F0: main (hello_c.c:18) On Sat, Oct 1, 2016 at 1:28 AM, Emani, Murali <ema...@llnl.gov> wrote: > Attached is a sample of memory tracing using valgrind for malloc/free. > — > Murali > > > From: devel <devel-boun...@lists.open-mpi.org> on behalf of Gilles > Gouaillardet <gilles.gouaillar...@gmail.com> > Reply-To: Open MPI Developers <devel@lists.open-mpi.org> > Date: Friday, September 30, 2016 at 7:14 AM > > To: Open MPI Developers <devel@lists.open-mpi.org> > Subject: Re: [OMPI devel] Memory trace using valgrind in OpenMPI > > Can you provide a sample of the valgrind output ? > I do not believe there should be any hex there > > Cheers, > > Gilles > > On Friday, September 30, 2016, Emani, Murali <ema...@llnl.gov> wrote: >> >> Thanks Gilles,I’ve tried using these options but still cannot get the >> trace in the source code. >> >> — >> Murali >> >> >> From: devel <devel-boun...@lists.open-mpi.org> on behalf of Gilles >> Gouaillardet <gilles.gouaillar...@gmail.com> >> Reply-To: Open MPI Developers <devel@lists.open-mpi.org> >> Date: Wednesday, September 28, 2016 at 3:22 PM >> To: Open MPI Developers <devel@lists.open-mpi.org> >> Subject: Re: [OMPI devel] Memory trace using valgrind in OpenMPI >> >> Hi, >> >> you might want to rebuild Open MPI with the previous configure command >> line, and append >> --disable-dlopen CFLAGS='-g -O0' >> >> by default, components are built into their own lib (for example >> mca_btl_tcp.so) which is dlopen'ed and dlclose'd at runtime, and that might >> not be supported by post mortem tools >> >> Cheers, >> >> Gilles >> >> On Thursday, September 29, 2016, Emani, Murali <ema...@llnl.gov> wrote: >>> >>> Hi all, >>> >>> I am trying to perform memory allocation analysis in OpenMPI using >>> valgrind and use addr2line to get the location in the source code in the >>> application and the library. >>> >>> I have compiled OpenMPI with valgrind using >>> >>> ./configure —prefix=<path> —enable-debug —enable-mem-debug >>> —enable-memchecker —with-valgrind=/path-to-valgrind/ >>> >>> I compile and run the sample code, myapp.c as >>> mpicc –g myapp.c –o myapp >>> mpirun –np <num_processes> valgrind <valgrind-options> ./myapp >>> >>> The valgrind output yields hex codes and I try to retrieve the line in >>> the source code using addr2line. This yields the exact line in the source >>> code of myapp.c but not in OpenMPI source. I was expecting it to get the >>> exact location and line numbers in OpenMPI too as it is compiled with debug >>> info enabled. >>> >>> Can someone provide any pointers if this is the correct way or/and how to >>> achieve this? >>> >>> — >>> Murali >>> > > _______________________________________________ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
