|
From: Srivatsan R. <jug...@ya...> - 2006-10-20 13:53:59
|
Hi People,
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.
Regards
vatsan.
"MAN'S EGO IS THE FOUNTAINHEAD OF HUMAN PROGRESS"
Ayn Rand.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
|
|
From: David E. <da...@2g...> - 2006-10-22 13:55:26
|
On Fri, 2006-10-20 at 06:53 -0700, Srivatsan Ramanujam wrote: > Hi People, > > 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) > -------------------------------------- > > [snip] The source to ABCParser::parseString() would be useful to get a better idea of what is going on. Maybe you should try to add the below defines to the CXXFLAGS for the whole project, and rebuild everything. That should add validations to certain STL operations and maybe that will pinpoint the error better than valgrind: -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC \David |