From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5983 invoked by alias); 26 Oct 2006 16:06:30 -0000 Received: (qmail 5975 invoked by uid 22791); 26 Oct 2006 16:06:30 -0000 X-Spam-Check-By: sourceware.org Received: from mail.zeugmasystems.com (HELO zeugmasystems.com) (192.139.122.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Oct 2006 16:06:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Valgrind - exact leak location. Date: Thu, 26 Oct 2006 16:06:00 -0000 Message-ID: <66910A579C9312469A7DF9ADB54A8B7D418250@exchange.ZeugmaSystems.local> From: "Kaz Kylheku" To: "Srivatsan Ramanujam" , X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2006-10/txt/msg00257.txt.bz2 > Hi People, >=20 > I have been trying to run valgrind to detect leaks in > my backend C++ algorithm. But what valgrind has detected is an invalid read, not a leak. > 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. What leak? The routine is dereferencing an invalid pointer. > Is there a way out? Can valgrind give me the exact > line number in a file where the "invalid read" > occured? Let's look at it: =3D=3D9984=3D=3D by 0x1B97AB4E: ABCParser::parseString() (stl_vector.h:5= 01) The invalid read did occur in stl_vector.h:501. But that is the middle of an inlined function that was incorporated into the body of parseString(). It doesn't have its own stack frame, which would give a backtrace to the parent function. Inlining is an optimization which, as you can see, can interfere with debugging. Have you thought of recompiling the code with inlining disabled? > How can I make valgrind point out the exact location > of the error in my code? In what way is is the machine address 0x1B97AB4E not an exact location? Compile with -g, and then use objdump -S to an assembly listing annotated with the source code lines.