> So, this is a complete and utter hack. It should never ever get near
> any production code, ever! Just so that is very clear. It has one and
> only one purpose, getting enough information to get a back trace of
> every single memory allocation you are interested in. Credit where
> credit is due, I stole the idea of this code from the guy who wrote
> libbtrace, search on freshmeat for it. Basically, he gave me the
> pointer to the backtrace function in the glibc2. A lot of the reasons
> below are from his docs.
Woah! Ok, this is indeed a hack ;)
A usefull one imo, but it poses a lot of requirements on the platform.
I know the output of the pools debug mode is very (if not extremely)
verbose, but it is more portable and with a bit of grep magic
you can get all the info you need. I recently added another option
to --enable-pool-debug: verbose-alloc. This will spit out all the
invocations of apr_p[c]alloc. This only leaves one more point in
the pools code where memory is allocated: apr_pvsprintf.
Btw, I liked your walk_pool_tree, I know I can use that (or at least
the concept). Thanks.
[...]
> If anybody wants a more portable version that isn't quite as filtered, I
> can jimmy up something using gdb, .gdbinit, expect and/or shell to get
> more detailed information including all the arguments of the calls, but
> that seemed less useful for tracking down the worst offenders then this is.
>
> Honest not everything I write is this much of a total hack. Results
> count and style doesn't when bug hunting.
;)
Thanks for the effort. We definately need some decent bug hunting
tools. I am staring at some code at the moment that will hopefully
make our lives a bit easier (relies heavily on mprotect), by segfaulting
on us at the point the app does something we don't want. This is
the behaviour electric fence gives you, with the bonus that we can
write protect memory we know shouldn't be touched. This will be the
more portable implementation of apr_pool_lock, that wrowe introduced
for win32 (and I left out in the rewrite)...
Sander
> Thanks,
>
> Kirby
>
> PS: You already know how to fish, I've seen your code :-), the above is
> a demonstration of how to gut the fish and turn it into fish spam....
*grin*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:04 2006