Sander,
Sander Striker wrote:
>>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.
>
Given it is my only platform, I don't mind. Yes an unfortuante side
affect of how it was done. I did some poking about in glibc, and
actually it appears that it backtrace might be supported on more
platforms, but I couldn't test that if my life depended on it. So
somebody with a different arch/platform might try it. I have no way of
testing it. It looks like it might work on any platform using glibc on
the following list:
./sysdeps/i386/backtrace.c
./sysdeps/powerpc/backtrace.c
./sysdeps/s390/s390-32/backtrace.c
./sysdeps/s390/s390-64/backtrace.c
./sysdeps/generic/backtrace.c
So I might have missed the boat on how portable it is. Sorry.
All those had the same function that takes the same arguments, I presume
the symantics are the same. I thought the libbtrace docs said it was a
lot less portable, but maybe it is slightly more portable then I put
forward. No, it can't get folded into the main tree all things
considered. I know there is a way to do in win32 on a VC++ compiler
also, but it has been to long, I don't remember the details.
> 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.
>
I stole the idea from the apr code. Yeah it isn't at all threadsafe,
but I didn't have any way of testing that. I tried to leave it obvious
that it was broken rather then mock up that it might do the right thing.
There is a identical functionality in the count the memory recursively,
just strip out the summation and put in the function pointer if I
remember correctly.
[..snip...]
Thanks,
Kirby
---------------------------------------------------------------------
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:05 2006