On Tue, 18 Nov 1997, Daniel Ryde wrote:
> I'm testing the real 2.0.32 now but I guess it will have the same bug.
It has.
> I have a suggestion here: would'nt it be a Good Thing (tm) to always have
> some latent code that can be enabled at compiletime, to generate some
> general malloc/free statistics.
> In some central kernel-memory allocating place, like in kmalloc.c
> (this seems like the most resonable), put two hashed tables, one
> for allocations and one for freeings. Both tables should hash the
> address from where it was called and add the amount of memory
> allocated/freed to its value. Then I guess it should be pretty simple to
> put these tables into the proc filesystem and from there spot the leak.
> The hash algoritm could be made pretty simple by just taking the least
> significant byte of the calling address and use that as the hash.
>
> I guess this would generally save a lot of brain time when debugging these
> obscure memory leaks.
>
> Useful? Possible? Comments? Other ideas?
Wow! Incredible respose.
Best Regards
Daniel Ryde, System Administrator
__________________________________________________________________________
Tripnet AB Visit Address: Telephone: +46 31 7252500
Box 5071 Avagen 42 Facsimile: +46 31 7252501
S-402 22 GOTEBORG GOTEBORG Email: ryde@tripnet.se
Sweden Sweden