|
From: Howard C. <hy...@sy...> - 2006-01-26 15:42:14
|
Ashley Pittman wrote: > On Thu, 2006-01-26 at 07:26 +0100, Oswald Buddenhagen wrote: > >> On Wed, Jan 25, 2006 at 06:36:19PM -0800, Graydon Hoare wrote: >> >>> I'm working on characterizing mozilla's memory use, in order to >>> eventually make it use less. I am hoping to use valgrind for this. >>> >>> >> ok, maybe i'm totally wrong, but i would not use valgrind for this. >> as you want to do allocation and leak tracking only, you don't need any >> instrumentation except wrapping the allocator functions (which, i guess, >> the nspr(?) does anyway) and doing a snapshot each time you need it >> (memcheck does the same, afaik). that would mean that integrating a >> *way* more lightweight "classical" memory debugger library would be more >> appropriate. depends on what else you want to track at the same time ... >> > > Sorry if this is too off-topic for this list... > > I've done exactly this to track memory leaks in programs, it's actually > quite easy once you know how. > > There are hooks inside libc (man 3 malloc_hook) you can use to intercept > every malloc/calloc/memalign/free call from everywhere in the > application/library's it's using (you don't even need the source to do > this). These callbacks are given the size and base of the buffer but > also the return address for the function that called malloc() in the > first place. > Those hooks only exist for glibc. My FunctionCheck code shows how to intercept malloc/etc. for any libdl-based dynamic library platform (e.g. Solaris, Irix, Linux, etc...) http://www.highlandsun.com/hyc/#fncchk -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/ |