Hello! On Fri, Mar 31, 2006 at 04:45:55PM -0800, David Higgs wrote: >> BTW: it does not seem to be a problem with mutex/cond: I "saved" >> those in an array for reuse (instead of calling _init()/_destroy() >> for every invocation) and even then the size grows. I'll try to >> build a debugging version of libc (with some malloc checks) over >> the weekend.
>Another old trick is to let your program eat memory for a good while, >and then break into its execution. Randomly inspect some of the >allocated memory your program still holds; there is a very good chance >you're looking at leaked structures. Hopefully you can figure out >what those structures are, and track down what's allocating so many. I've done that in a somewhat more sophisticated way: Wrap malloc and friends to print their allocation size, address, *and a backtrace* (just the addresses in hex), to a separate file descriptor. Then, a separate program sets up that FD with a pipe, reads from that, matches up malloc/calloc and free, taking realloc into account properly, of course. And that separate program can display the top N allocation sizes sorted by their backtrace. The separate program can also read nm output so the backtraces are printed symbolically. However, I'm not sure whether I could open-source that stuff, because I wrote it at and for work. And of course, it needs a little architecture dependent code for the backtrace stuff. And a bit of hacking around (toolchain specific) so I can intercept malloc etc., and at the same time use the original malloc from libc in the end (i.e. I don't completely replace malloc - I've got an own malloc implementation, too, but that's orthogonal to my malloc tracer stuff). In fact I like both things, both my malloc tracer, and my own malloc implementation (mmap based, somewhat tuned for speed, and for as compact as reasonably possible vm usage, and *relatively* simple code still, OTOH, no options like in BSD's malloc, no own randomization/guard pages/... stuff, OTOOH, a bit faster than OpenBSD's malloc in some cases, it seems). Kind regards, Hannah.
