Valgrind - exact leak location.

Valgrind - exact leak location.

[Srivatsan Ramanujam]

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 

Re: Valgrind - exact leak location.

[Andrew Haley]

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.

Re: Valgrind - exact leak location.

[William Gallafent]

On Thursday 26 October 2006 11:04, Andrew Haley wrote:
> 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.

You can make valgrind automatically start the debugger when it 
detects an error using the --db-attach=yes command line option.

-- 
Bill Gallafent.

Re: Valgrind - exact leak location.

[Neil Ferguson]

Not a GCC question, but I'll have a pot at it anyway.

For future reference, the right place to ask this sort of question is the 
valgrind-users mailing list - see here:

http://www.valgrind.org/support/mailing_lists.html

>  > ==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?

Valgrind *has* given you the line number, but the error happens to show up 
inside a piece of inlined code from stl_vector.h. There are two ways to handle 
this:

1. Get Valgrind to start a debugger for you when the error happens - run 
'valgrind --help', then look for the '--db-attach' & '--db-command' options.

2. The fact that this happens in inlined vector code means that your method 
must have been performing a vector operation at the time. You may find that 
narrows things down enough to skim ABCParser::parseString() more quickly. If 
you look at the area around line 501 in stl_vector.h, you may be able to find 
out which vector operation was being called, narrowing things down still further.

Hope that helps!

Neil.

Re: Valgrind - exact leak location.

[Srivatsan Ramanujam]

Hi Neil,

Thanks for your inputs.
Well by "exact location of error" I meant the line
number in my program file where the error occured.

As you can see

"ABCParser::parseString()(stl_vector.h:501)"

it says the error occured inside the function
parseString() but it doesn't indicate which line
number inside this function. the parseString()
function by itself runs to over 2000 lines(not written
by me).I know that the error is occuring when a
read/write is being performed beyond the boundary of
the vector variables used in the parseString()
function, but unfortunately because of its sheer size
I am unable to zero in on the exact location(line
number).

I tried inserting some print statements and zeroed in
on the invalid read but it is a pretty dumb approach,
I shall try using the debugger tip you gave me.

Thanks again
vatsan.

PS: thanks for pointing me to the valgrind mailing
list, I have already posted there, however I did not
get responses, so I thought of posting in the gcc
forum as I believed it had something to do with the
debugger flags associated with the gcc Makefiles.





--- Neil Ferguson <nferguso@eso.org> wrote:

> Not a GCC question, but I'll have a pot at it
> anyway.
> 
> For future reference, the right place to ask this
> sort of question is the 
> valgrind-users mailing list - see here:
> 
> http://www.valgrind.org/support/mailing_lists.html
> 
> >  > ==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?
> 
> Valgrind *has* given you the line number, but the
> error happens to show up 
> inside a piece of inlined code from stl_vector.h.
> There are two ways to handle 
> this:
> 
> 1. Get Valgrind to start a debugger for you when the
> error happens - run 
> 'valgrind --help', then look for the '--db-attach' &
> '--db-command' options.
> 
> 2. The fact that this happens in inlined vector code
> means that your method 
> must have been performing a vector operation at the
> time. You may find that 
> narrows things down enough to skim
> ABCParser::parseString() more quickly. If 
> you look at the area around line 501 in
> stl_vector.h, you may be able to find 
> out which vector operation was being called,
> narrowing things down still further.
> 
> Hope that helps!
> 
> Neil.
> 


"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 

Re: Valgrind - exact leak location.

[Srivatsan Ramanujam]

Hi Andrew,

Thanks for your inputs.
Well by "exact location of error" I meant the line
number in my program file where the error occured.

As you can see

"ABCParser::parseString()(stl_vector.h:501)"

it says the error occured inside the function
parseString() but it doesn't indicate which line
number inside this function. the parseString()
function by itself runs to over 2000 lines(not written
by me).I know that the error is occuring when a
read/write is being performed beyond the boundary of
the vector variables used in the parseString()
function, but unfortunately because of its sheer size
I am unable to zero in on the exact location(line
number).

I tried inserting some print statements and zeroed in
on the invalid read but it is a pretty dumb approach,
I shall try using the debugger tip you gave me.

Thanks again
vatsan.

--- Andrew Haley <aph@redhat.com> wrote:

> 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.
> 
> 


"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 

Re: Valgrind - exact leak location.

[Andrew Haley]

Srivatsan Ramanujam writes:
 > Hi Neil,
 > 
 > Thanks for your inputs.
 > Well by "exact location of error" I meant the line
 > number in my program file where the error occured.
 > 
 > As you can see
 > 
 > "ABCParser::parseString()(stl_vector.h:501)"
 > 
 > it says the error occured inside the function
 > parseString() but it doesn't indicate which line
 > number inside this function.

Line 501.

Re: Valgrind - exact leak location.

[Srivatsan Ramanujam]

sin't line 501 inside stl_vector.h?
That simply indicates the overloading of [] operator
for a vector.

line number 501 inside my program merely sets a value
for an INTEGER variable.

thanks
vatsan.

--- Andrew Haley <aph@redhat.com> wrote:

> Srivatsan Ramanujam writes:
>  > Hi Neil,
>  > 
>  > Thanks for your inputs.
>  > Well by "exact location of error" I meant the
> line
>  > number in my program file where the error
> occured.
>  > 
>  > As you can see
>  > 
>  > "ABCParser::parseString()(stl_vector.h:501)"
>  > 
>  > it says the error occured inside the function
>  > parseString() but it doesn't indicate which line
>  > number inside this function.
> 
> Line 501.
> 


"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 

Re: Valgrind - exact leak location.

[Andrew Haley]

Please don't top-post.

 > --- Andrew Haley <aph@redhat.com> wrote:
 > 
 > > Srivatsan Ramanujam writes:
 > >  > Hi Neil,
 > >  > 
 > >  > Thanks for your inputs.
 > >  > Well by "exact location of error" I meant the
 > > line
 > >  > number in my program file where the error
 > > occured.
 > >  > 
 > >  > As you can see
 > >  > 
 > >  > "ABCParser::parseString()(stl_vector.h:501)"
 > >  > 
 > >  > it says the error occured inside the function
 > >  > parseString() but it doesn't indicate which line
 > >  > number inside this function.
 > > 
 > > Line 501.

Srivatsan Ramanujam writes:
 > sin't line 501 inside stl_vector.h?
 > That simply indicates the overloading of [] operator
 > for a vector.
 > 
 > line number 501 inside my program merely sets a value
 > for an INTEGER variable.

Well, that is the best that is known to the compiler.  It might be
correct; in any case it's all the information we have.

It might be worth rebuilding without optimization to get a more
accurate idea of what's going on.

Andrew.

Re: Valgrind - exact leak location.

[Srivatsan Ramanujam]

--- Andrew Haley <aph@redhat.com> wrote:

> Please don't top-post.
> 
>  > --- Andrew Haley <aph@redhat.com> wrote:
>  > 
>  > > Srivatsan Ramanujam writes:
>  > >  > Hi Neil,
>  > >  > 
>  > >  > Thanks for your inputs.
>  > >  > Well by "exact location of error" I meant
> the
>  > > line
>  > >  > number in my program file where the error
>  > > occured.
>  > >  > 
>  > >  > As you can see
>  > >  > 
>  > >  > "ABCParser::parseString()(stl_vector.h:501)"
>  > >  > 
>  > >  > it says the error occured inside the
> function
>  > >  > parseString() but it doesn't indicate which
> line
>  > >  > number inside this function.
>  > > 
>  > > Line 501.
> 
> Srivatsan Ramanujam writes:
>  > sin't line 501 inside stl_vector.h?
>  > That simply indicates the overloading of []
> operator
>  > for a vector.
>  > 
>  > line number 501 inside my program merely sets a
> value
>  > for an INTEGER variable.
> 
> Well, that is the best that is known to the
> compiler.  It might be
> correct; in any case it's all the information we
> have.
> 
> It might be worth rebuilding without optimization to
> get a more
> accurate idea of what's going on.
> 
> Andrew.
> 
> 

oh sorry... I am new here...didn't know the
conventions used...shall not top post.

Oh...so that is the final level of resolution the
compiler can give on the error? 

I have used the db-attach option now, and I believe i
am making some progress through the use of gdb(which i
am new to)....thanks again for all your help.

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 

Re: Valgrind - exact leak location.

[John Love-Jensen]

Hi Srivatsan,

> Isn't line 501 inside stl_vector.h?

Yes.

If you want, break into the debugger (gdb) and do a backtrace to see where
up the stack which frame and what line your routine was at.

Make sure you compile your code with -g.

--Eljay

Re: Valgrind - exact leak location.

[Srivatsan Ramanujam]

--- John Love-Jensen <eljay@adobe.com> wrote:

> Hi Srivatsan,
> 
> > Isn't line 501 inside stl_vector.h?
> 
> Yes.
> 
> If you want, break into the debugger (gdb) and do a
> backtrace to see where
> up the stack which frame and what line your routine
> was at.
> 
> Make sure you compile your code with -g.
> 
> --Eljay
> 
> 

thanks...yeah I am currently running the gdb on my
program, looks promising.

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 

Re: Valgrind - used gdb

[Srivatsan Ramanujam]

Hi all,

I used db--detach option to invoke the debugger from
valgrind when the invalid read occurred, here is what
i got.

----------------------------------
Program received signal SIGSTOP, Stopped (signal).
ABCParser::parseString (this=0x344b86f0) at
stl_vector.h:501
501           operator[](size_type __n) { return
*(begin() + __n); }
----------------------------------

thats where the invalid read occurred.

Now i used backtrace to get where it was invoked.


----------------------------------
gdb) backtrace
#0  ABCParser::parseString (this=0x344b86f0) at
stl_vector.h:501
#1  0x341bb8f3 in ABCParser::execute (this=0x344b86f0)
at ABCParser.cpp:97
#2  0x080499aa in main (argc=2, argv=0x9c5fdc64) at
testAlgo.cpp:31

----------------------------------
it again says that the error occured in the function.
parseString() (but no line number is shown :-( )

I tried looking into what stl_vector.h is doing at the
specified lines using the list command...and here is
what i got.

-----------------------------------
ABCParser::parseString (this=0x344b86f0) at
stl_vector.h:501
501           operator[](size_type __n) { return
*(begin() + __n); }
(gdb) list
496            *  Note that data access with this
operator is unchecked and
497            *  out_of_range lookups are not
defined. (For checked lookups
498            *  see at().)
499            */
500           reference
501           operator[](size_type __n) { return
*(begin() + __n); }
502
503           /**
504            *  @brief  Subscript access to the data
contained in the %vector.
505            *  @param n The index of the element
for which data should be
(gdb)
-----------------------------------------------------

it doesn't seem to say anything more....i know that
the invalid read is cause when a vector variable is
read beyond its boundary....but which one?? there are
so many vectors in my prog...and it is a one huge
function.

please shed some light.

thanks
vatsan




--- John Love-Jensen <eljay@adobe.com> wrote:

> Hi Srivatsan,
> 
> > Isn't line 501 inside stl_vector.h?
> 
> Yes.
> 
> If you want, break into the debugger (gdb) and do a
> backtrace to see where
> up the stack which frame and what line your routine
> was at.
> 
> Make sure you compile your code with -g.
> 
> --Eljay
> 
> 


"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 

Re: Valgrind - used gdb

[John Love-Jensen]

Hi Srivatsan,

> it again says that the error occured in the function.
> parseString() (but no line number is shown :-( )

Isn't this...

> #0  ABCParser::parseString (this=0x344b86f0) at
> stl_vector.h:501
> #1  0x341bb8f3 in ABCParser::execute (this=0x344b86f0)
> at ABCParser.cpp:97

...in parseString?

Remember, std::vector is a template, which means that it is instantiated,
and many of its routines are inlined.  Maybe use the -fno-inline flag.

What happens when you step through the routine?

Divide and conquer the bugs.  Set breadcrumb breakpoints inching forward,
such as "good to line 80"... "now good to line 86"... hmmm "broken between
line 86 and line 105" (the bug gets triggered somewhere in there)... restart
the app, get to line 86, single-step... blows up in line 92, set a break
point at line 91... oops, there is no line 91 since that's a comment...
breakpoint at line 90.  Restart.  Line 90, okay single-step and dive into
subroutines.  Subroutine A is called, line 1000 of A is good, 1001, 1002,
1003, 1007 broken.  Hmm, bug triggers between 1003 and 1007.  Restart.
Breakpoint at 1003.  Continue.  Hits breakpoint 90.  Continue.  Hits
breakpoint 1003.  Dive into sub-subroutine B.  Single-step.  Et cetera.

> it doesn't seem to say anything more....i know that
> the invalid read is cause when a vector variable is
> read beyond its boundary....but which one?? there are
> so many vectors in my prog...and it is a one huge
> function.

Sounds like your function is TOO huge.  Strive to make routines do "one unit
of work".  If the cyclometric complexity of the routine is greater than, oh,
7 or so, it's likely doing too much.

And "too much" translates into "hard to understand, hard to maintain, hard
to debug".

HTH,
--Eljay

Re: Valgrind - used gdb

[Srivatsan Ramanujam]

Hi John

--- John Love-Jensen <eljay@adobe.com> wrote:

> Hi Srivatsan,
> 
> > it again says that the error occured in the
> function.
> > parseString() (but no line number is shown :-( )
> 
> Isn't this...
> 
> > #0  ABCParser::parseString (this=0x344b86f0) at
> > stl_vector.h:501
> > #1  0x341bb8f3 in ABCParser::execute
> (this=0x344b86f0)
> > at ABCParser.cpp:97
> 
> ...in parseString?

parseString() is a function in my file ABCParser.cpp
parseString() is invoked by the execute() function in
the same file ABCParser.cpp.

however the vector stuff like you said is perhaps
inline code.....but still why should it not atleast
tell me what were the lines in parseString() before
the inlined vector code??



> 
> Remember, std::vector is a template, which means
> that it is instantiated,
> and many of its routines are inlined.  Maybe use the
> -fno-inline flag.
> 
> What happens when you step through the routine?
> 

dividing and conquering...I should try (I have not
used gdb before....I used to use the dumb way of
writing print statements to use divide and
conquer..... it did help...but i am not very happy
with that approach).

what does the -fno-inline flag do? should i include
this along with that db-attach flags?




> Divide and conquer the bugs.  Set breadcrumb
> breakpoints inching forward,
> such as "good to line 80"... "now good to line
> 86"... hmmm "broken between
> line 86 and line 105" (the bug gets triggered
> somewhere in there)... restart
> the app, get to line 86, single-step... blows up in
> line 92, set a break
> point at line 91... oops, there is no line 91 since
> that's a comment...
> breakpoint at line 90.  Restart.  Line 90, okay
> single-step and dive into
> subroutines.  Subroutine A is called, line 1000 of A
> is good, 1001, 1002,
> 1003, 1007 broken.  Hmm, bug triggers between 1003
> and 1007.  Restart.
> Breakpoint at 1003.  Continue.  Hits breakpoint 90. 
> Continue.  Hits
> breakpoint 1003.  Dive into sub-subroutine B. 
> Single-step.  Et cetera.
> 
> > it doesn't seem to say anything more....i know
> that
> > the invalid read is cause when a vector variable
> is
> > read beyond its boundary....but which one?? there
> are
> > so many vectors in my prog...and it is a one huge
> > function.
> 
> Sounds like your function is TOO huge.  Strive to
> make routines do "one unit
> of work".  If the cyclometric complexity of the
> routine is greater than, oh,
> 7 or so, it's likely doing too much.


yeah that is the whole problem....the function is too
huge...but it is NOT MINE :-), someone else had
written it (who isn't much familiar with programming
as he is more of an algo expert....), rewriting this
program into smaller chunks wud take more time...so it
is not an option as of now.....



> 
> And "too much" translates into "hard to understand,
> hard to maintain, hard
> to debug".
> 
> HTH,
> --Eljay


any further directions wud be really helpful.

thanks
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 

Including static libraries

[Sameer Naik]

*Hello,
    im creating a shared library. and trying to link it to a static 
library with extentions of the form video.a470MV.
im including the whole path of the library in the LDFLAGS 
(/home/sameersbn/libs/video.a470MV)
these are included in the Makefile.am file.
when the linking is done, no errors are flashed and the linking 
procedure completes without complains. but if i run the nm command on 
the library created, i dont see any symbols of the static library in the 
symbol table.
instead if i extract the .o470MV file from the static library and rename 
them to .o and archive it as .a and do the linking again, then  it works 
fine  and the symbol table shows  the new  symbol entries.
i would like to know how to get my .a470MV libraries to successfully get 
linked into my new library.
plz help

thanks in advance
tc
sameer
*

Re: Including static libraries

[Brian Budge]

I believe that if you want to statically link a file with complete
path like that, you don't use the normal linker flags with gcc.  You
can just treat the file as if it were a big .o file and just supply
the path i.e.:

was
gcc -l/home/sameersbn/libs/video.a470MV
(at least this is what I understand from your email)

becomes
gcc /home/sameersbn/libs/video.a470MV

  Brian

On 10/26/06, Sameer Naik <sameer@nextbitcpu.com> wrote:
> *Hello,
>     im creating a shared library. and trying to link it to a static
> library with extentions of the form video.a470MV.
> im including the whole path of the library in the LDFLAGS
> (/home/sameersbn/libs/video.a470MV)
> these are included in the Makefile.am file.
> when the linking is done, no errors are flashed and the linking
> procedure completes without complains. but if i run the nm command on
> the library created, i dont see any symbols of the static library in the
> symbol table.
> instead if i extract the .o470MV file from the static library and rename
> them to .o and archive it as .a and do the linking again, then  it works
> fine  and the symbol table shows  the new  symbol entries.
> i would like to know how to get my .a470MV libraries to successfully get
> linked into my new library.
> plz help
>
> thanks in advance
> tc
> sameer
> *
>

Re: Valgrind - used gdb

[John Love-Jensen]

Hi Srivatsan,

> however the vector stuff like you said is perhaps
> inline code.....but still why should it not atleast
> tell me what were the lines in parseString() before
> the inlined vector code??

Because the lines in parseString() before the inlined vector code isn't
where the problem was triggered.  Those lines are before where the problem
was triggered.  The backtrace reports where things are at, not at where
things are where you want them to be -- the psychic gdb isn't available yet.

#define JOKE
I heard that Richard Stallman had the psychic gdb working under MULTICS, but
it's not quite functional under Unix yet.
#undef JOKE

That doesn't mean that where the problem was triggered is where the problem
resides.  It is quite possible that a problem is located far, far away from
where the problem triggers, in both time and space (code).  Nothing worse
than trying to figure out why a program crashes where the actual bug sets up
things 10 minutes earlier, and in entirely unrelated translation units.  I
ran into that issue once-upon-a-time because of interleaved throw/catch and
setjmp/longjmp code.

Those kinds of bugs are much harder to find.

HTH,
--Eljay

Re: Valgrind - used gdb

[Neil Ferguson]

Srivatsan Ramanujam wrote:

<snip>

> what does the -fno-inline flag do? should i include
> this along with that db-attach flags?

'-fno-inline' is a compiler flag, not a Valgrind flag. It tells the compiler 
not to inline anything, which should hopefully give you a deeper, but more 
informative stack trace in your debugger.

You'll need to add it to your build setup somehow - set CFLAGS in your 
environment, for example, or edit your Makefile.

>> Sounds like your function is TOO huge. Strive to make routines do "one
>> unit of work". If the cyclometric complexity of the routine is greater
>> than, oh, 7 or so, it's likely doing too much.
> 
> yeah that is the whole problem....the function is too huge...but it is NOT
> MINE :-), someone else had written it (who isn't much familiar with
> programming as he is more of an algo expert....), rewriting this program
> into smaller chunks wud take more time...so it is not an option as of
> now.....

An algorithm expert should be *exactly* the person to break an algorithm into 
tractable subcomponents.

>>And "too much" translates into "hard to understand,
>>hard to maintain, hard to debug".
>>
>>HTH,
>>--Eljay
> 
> any further directions wud be really helpful.
> 
> thanks
> vatsan.

If you can't compile with '-fno-inline', you're going to have to go with one 
of the divide-and-conquer approaches John described. There's nothing else you 
can do in a situation like this.

Neil.

Re: Valgrind - used gdb

[Srivatsan Ramanujam]

Hi Neil

--- Neil Ferguson <nferguso@eso.org> wrote:

> Srivatsan Ramanujam wrote:
> 
> <snip>
> 
>> '-fno-inline' is a compiler flag, not a Valgrind
> flag. It tells the compiler 
> not to inline anything, which should hopefully give
> you a deeper, but more 
> informative stack trace in your debugger.
> 
> You'll need to add it to your build setup somehow -
> set CFLAGS in your 
> environment, for example, or edit your Makefile.
> 


yeah I figured that out and tried doing that...not
much help.

>
> An algorithm expert should be *exactly* the person
> to break an algorithm into 
> tractable subcomponents.

true...but those are beyond my control :-)
ppl join and leave organisations backhere all too
frequently. :-)


> 
> If you can't compile with '-fno-inline', you're
> going to have to go with one 
> of the divide-and-conquer approaches John described.
> There's nothing else you 
> can do in a situation like this.
> 
> Neil.


thanks again,.....well i am left then with only that
option....shall try doing that.

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 

RE: Valgrind - exact leak location.

[Kaz Kylheku]

> Hi People,
> 
> 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:

==9984==    by 0x1B97AB4E: ABCParser::parseString() (stl_vector.h:501)

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.