<div dir="ltr"><div><div><div>Relevant code for accounting still objects:<br><a href="https://gist.github.com/vyzo/ab4219382c0870779991d4c701921d2c">https://gist.github.com/vyzo/ab4219382c0870779991d4c701921d2c</a><br><br></div>The limitation is that the still_objs_ is per processor, and not vm-wide.<br></div>Does that mean we would have to crawl all processors in SMP?<br><br></div>-- vyzo<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 1, 2018 at 3:16 PM, Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Feb 1, 2018, at 8:06 AM, Dimitris Vyzovitis <<a href="mailto:vyzo@hackzen.org">vyzo@hackzen.org</a>> wrote:<br>
><br>
> thanks Guillaume!<br>
><br>
> this is a great start for me -- i am helping fare debug a memory leak, and it's really hard to identify<br>
> without dumping the heap to see what kind of object is leaking.<br>
<br>
</span>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.<br>
<br>
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”.<br>
<br>
So the idea would be to check at the end of a program if there are any still objects with non-zero ref counts.<br>
<span class="HOEnZb"><font color="#888888"><br>
Marc<br>
<br>
</font></span></blockquote></div><br></div>