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