Relevant code for accounting still objects:
https://gist.github.com/vyzo/ab4219382c0870779991d4c701921d2c

The limitation is that the still_objs_ is per processor, and not vm-wide.
Does that mean we would have to crawl all processors in SMP?

-- vyzo


On Thu, Feb 1, 2018 at 3:16 PM, Marc Feeley <feeley@iro.umontreal.ca> wrote:
> On Feb 1, 2018, at 8:06 AM, Dimitris Vyzovitis <vyzo@hackzen.org> wrote:
>
> thanks Guillaume!
>
> this is a great start for me -- i am helping fare debug a memory leak, and it's really hard to identify
> without dumping the heap to see what kind of object is leaking.

For your information I discovered a few memory leaks with the networking functions.  They were due to “sockaddr” structures being converted to “still” Scheme objects with a reference count = 1, but the reference count was never decremented (with ___release_scmobj).  This has been fixed in the recent UDP commit.

I believe that this kind of situation might exist in other places in the runtime system.  So it might be useful to debug this to have a function that returns a list of all the “still” Scheme objects that have a reference count != 0.  This should be easy to write… the GC maintains a list of the still objects in the C variable “still_objs”.

So the idea would be to check at the end of a program if there are any still objects with non-zero ref counts.

Marc