There's a bit of a bug in scm_must_realloc and its scm_mallocated
counting in 1.6.
If you tell scm_must_realloc to decrease the size of a block, it
doesn't change scm_mallocated count, so when you later report the new
size in the free, the final scm_mallocated is off by the difference
(ie. bigger than it should be).
This occurs in the core with bignums when scm_i_adjbig trims off
excess digits from the end of a block. It might happen with
applications, though perhaps realloc to decrease isn't too common.
A little loop that shows the problem is
(while #t
(ash 1 256)
(gc)
(pk (assq-ref (gc-stats) 'bytes-malloced)))
The count printed keeps going up.
I'm inclined to remove the short-circuit
if (size <= old_size)
return where;
from scm_must_realloc, ie. if you ask to decrease a block then
actually do it, which is what 1.8 has now.
The alternative would be to leave no realloc() on decrease, but do
adjust scm_mallocated. That would mean scm_mallocated doesn't reflect
the amount of malloc actually in use, which wouldn't be a good thing
for the mtrigger stuff.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
