Who wants to have some fun memory debugging?

[Robert Fraser]

grauzone wrote:
> Wild guess: there's a false pointer, that keeps one element in the list 
> from being collected, and because the list-prev pointers are still 
> there, all following elements won't be collected either in consequence.
> 
> If I had time, I'd try two experiments:
> 1. before freeing everything, reset the prev field of each element; if 
> this makes the leak go away, my guess would probably be right

...But from where? The only pointers in the program (not counting the 
runtime) are on the stack. Even when the registers are zeroed, the 
problem still exists.

> 2. use the destructor (Data had to be a class) to keep track of how many 
> elements are actually freed by the GC (just a thread safe counter, 
> that's incremented in the ctor and decremented in the dtor); just to 
> find out if this is an internal GC problem, or if you have too many live 
> garbage

Interesting! I reduced it to 1000 allocations per iteration, and here 
are my results:

1000
1856
2744
3704
3768
3768
4600
4600
4600
4600
...

So it stabilizes at some point (albiet a point further than I'd like 
since for the actual application 4.6 * one usage would be around 600MB). 
So I guess it's just a lot less memory efficient than it should be.

Okay, thanks for all your help... This doesn't exactly *solve* my 
problem, but at least it means I can assume my code is good for now and 
hope for a new GC before I start running it on multi-gig data sets.