scm_must_realloc mallocated count in 1.6

* scm_must_realloc mallocated count in 1.6
@ 2006-03-19 22:46 Kevin Ryde
  2006-03-25 22:56 ` Marius Vollmer
  0 siblings, 1 reply; 2+ messages in thread
From: Kevin Ryde @ 2006-03-19 22:46 UTC (permalink / raw)

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

^ permalink raw reply	[flat|nested] 2+ messages in thread