life expectancy of allocated resources in a .so file - Linux
This is a discussion on life expectancy of allocated resources in a .so file - Linux ; Is there an equivalent to "Bounds Checker" for Linux that can let me
known when I trounce on memory? Somewhere I am walking on memory and
it's not occurring to me where.
Christian
http://christian.bongiorno.org...
-
life expectancy of allocated resources in a .so file
Is there an equivalent to "Bounds Checker" for Linux that can let me
known when I trounce on memory? Somewhere I am walking on memory and
it's not occurring to me where.
Christian
http://christian.bongiorno.org
-
Re: life expectancy of allocated resources in a .so file
"Sideswipe" writes:
> Is there an equivalent to "Bounds Checker" for Linux that can let me
> known when I trounce on memory?
There are several:
- valgrind (does excellent job of heap checking; very weak with
stack and globals); free/open-source
- gcc-4.x has -fmudflap, supposed to be very good, but in practice see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
- purify (same as valgrind for heap, slightly better for globals);
commercial
- Insure++ much better job with heap/stack/globals, but requires
rebuilding from source; commercial.
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
-
Re: life expectancy of allocated resources in a .so file
In article <1163605777.206861.170170@e3g2000cwe.googlegroups.c om>,
Sideswipe wrote:
> Is there an equivalent to "Bounds Checker" for Linux that can let me
> known when I trounce on memory? Somewhere I am walking on memory and
> it's not occurring to me where.
>
> Christian
> http://christian.bongiorno.org
I generally use:
1. Valgrind (valgrind.kde.org -- not tied to KDE window system)
2. GCC patched with Bounds Checking (sourceforge.net/projects/boundschecking
-- you can turn the bounds checking instrumentation on and off)
I do not usually use them together at the same time.
They each find different types of problems and with the right test cases, can
find huge numbers of potential issues in unclean code.
--
Scott Lacy Salley
http://scottlacysalley.blogspot.com