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@xxxxxxxxxx> 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
