Re: Valgrind - exact leak location.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Srivatsan Ramanujam writes:

 > I have been trying to run valgrind to detect leaks in
 > my backend C++ algorithm.
 > 
 > The algorithm is created as a shared library object, I
 > have writtten a small program testAlgo.cpp as an
 > interface to this algorithm and I am running valgring
 > on this program using 
 > 
 > make runval <filename>
 > 
 > where runval is defined as 
 > 
 > --------------------------------------
 > runval:	testAlgo
 > 	$(ENVIRON) $(MOREPATHS) valgrind --leak-check=full
 > --error-limit=no --show-reachable=no ./testAlgo $(FN)
 > --------------------------------------
 > 
 > here is a snapshot of an 'invalid read' error thrown
 > by Valgrind.
 > 
 > ------------------------------------------------
 > ==9984==
 > ==9984== Invalid read of size 4
 > ==9984==    at 0x1BA53642:
 > std::__default_alloc_template<true,
 > 0>::allocate(unsigned) (in
 > /usr/lib/libstdc++.so.5.0.7)
 > ==9984==    by 0x1B93F74A: int* std::vector<int,
 > std::allocator<int>
 > >::_M_allocate_and_copy<__gnu_cxx::__normal_iterator<int
 > const*, std::vector<int, std::allocator<int> > >
 > >(unsigned, __gnu_cxx::__normal_iterator<int const*,
 > std::vector<int, std::allocator<int> > >,
 > __gnu_cxx::__normal_iterator<int const*,
 > std::vector<int, std::allocator<int> > >) (in
 > /home/abc/xyz/rep/pkg/chem/moldata/2.4/lib/libmoldata.so)
 > ==9984==    by 0x1B93F337: std::vector<int,
 > std::allocator<int> >::operator=(std::vector<int,
 > std::allocator<int> > const&) (in
 > /home/abc/xyz/rep/pkg/chem/moldata/2.4/lib/libmoldata.so)
 > ==9984==    by 0x1B97AB4E: ABCParser::parseString()
 > (stl_vector.h:501)
 > ==9984==    by 0x1B975D34: ABCParser::execute()
 > (ABCParser.cpp:101)
 > ==9984==    by 0x80499A9: main (testAlgo.cpp:31)
 > ==9984==  Address 0x7 is not stack'd, malloc'd or
 > (recently) free'd
 > ----------------------------------------------------
 > 
 > the rogue operation is being performed inside
 > ABCParser::parseString()  however this is a very big
 > function and I am unable to painstakingly go thru it
 > to find out the possible source of leak.
 > 
 > Is there a way out? Can valgrind give me the exact
 > line number in a file where the "invalid read"
 > occured?
 > 
 > I read somewhere that compiling using the '-g' option
 > would do this, however I am not compiling a single
 > program.The algorithm has many dependencies and so I
 > am using the Makefile for compilation.
 > 
 > As a result valgrind is reporting an index in the
 > shared library object file that has been created, as
 > the location of the error.
 > 
 > 
 > How can I make valgrind point out the exact location
 > of the error in my code?
 > 
 > Any directions would be very helpful.

Well, it looks to me like you have got that exact location at
0x1BA53642.  It's not possible to be any more exact than that.

By default, libstdc++ compiles with -g, so that should be OK.  If I
were you I'd run the program inside gdb, so that when the Valgrind
'invalid read' error tripped I could have a look at where exactly it
was.

It's possible that there is a separate debuginfo package for
libstdc++, and you might have to load that.

Andrew.


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux