public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Andrew Haley <aph@redhat.com>
To: Srivatsan Ramanujam <juggernautvatsan@yahoo.com>
Cc: gcc-help@gcc.gnu.org
Subject: Re: Valgrind - exact leak location.
Date: Thu, 26 Oct 2006 10:04:00 -0000	[thread overview]
Message-ID: <17728.34862.751653.558627@zebedee.pink> (raw)
In-Reply-To: <20061026063228.5453.qmail@web57108.mail.re3.yahoo.com>

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.

  reply	other threads:[~2006-10-26 10:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-26  6:32 Srivatsan Ramanujam
2006-10-26 10:04 ` Andrew Haley [this message]
2006-10-26 11:44   ` William Gallafent
2006-10-26 11:57   ` Neil Ferguson
2006-10-26 12:10     ` Srivatsan Ramanujam
2006-10-26 12:25       ` Andrew Haley
2006-10-26 12:32         ` Srivatsan Ramanujam
2006-10-26 12:34           ` Andrew Haley
2006-10-26 12:37             ` Srivatsan Ramanujam
2006-10-26 12:38           ` John Love-Jensen
2006-10-26 12:40             ` Srivatsan Ramanujam
2006-10-26 13:34             ` Valgrind - used gdb Srivatsan Ramanujam
2006-10-26 13:51               ` John Love-Jensen
2006-10-26 13:58                 ` Srivatsan Ramanujam
2006-10-26 14:34                   ` John Love-Jensen
2006-10-26 14:51                   ` Neil Ferguson
2006-10-26 14:58                     ` Srivatsan Ramanujam
2006-10-26 14:06         ` Including static libraries Sameer Naik
2006-10-26 14:20           ` Brian Budge
2006-10-26 12:14   ` Valgrind - exact leak location Srivatsan Ramanujam
2006-10-26 16:06 Kaz Kylheku

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=17728.34862.751653.558627@zebedee.pink \
    --to=aph@redhat.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=juggernautvatsan@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).