ghc 5.02.2 FFI question

Simon Marlow simonmar@microsoft.com
Tue, 9 Apr 2002 14:17:28 +0100


Hi Bernie,

Thanks for a very well researched bug report.  I've looked into it, and
there is indeed a space leak (well, two in fact).  The reason I didn't
notice before was because I was looking at the heap stats rather than
using top; one of the leaks was with memory from malloc(), and the other
was memory obtained from our own arena allocator.

> My motivation is debugging. I was trying to implement a=20
> similar interface
> to the HugsInternals one.=20

Ah yes, I'd forgotten you were working on this.

> If I compile the program so that it does not call C
> (by modifying the definition of main so that it uses callLeak')
> then this is what top gives over 30 second samples:
>=20
> SIZE RSS  TIME
> --------------
> 1692 1692 0:00
> 1704 1704 0:30
> 1720 1720 1:00
> 1736 1736 1:30
> 1752 1752 2:00
> 1764 1764 2:30
>=20
> The process is still growing, but very slowly. I wouldn't expect
> it to grow at all, but I don't know the memory management of
> ghc well enough to be sure.

Ok, the first space leak was in the stable pointer table, as you
noticed.  It wasn't a bug as such, but we were waiting for a GC before
freeing entries in the stable pointer table (due to interactions with
StableNames), and in the case of your example it was a *long* time
between generation 1 GCs, which meant the stable pointer table grows in
the meantime.  This one is easily fixed.

The other leak was in our hash table implementation - I changed it to
use our arena allocator recently (for speed), and in the process removed
some of the recycling of hash table cells that was happening, so if
entries are repeatedly added and removed from the table then it would
grow without bound until the whole table is freed.  Creating/freeing a
stable pointer does exactly this, with the result that the stable
pointer hash table was leaking.  I've changed it back to the old
malloc/free version (that'll teach me to fiddle with working code ;-).

The reason the pure Haskell version was leaking less is perhaps because
major garbage collections were happening more often, but I didn't look
into this.

Once again, thanks for a great report.

Cheers,
	Simon