[gambit-list] Dumping the heap

Dimitris Vyzovitis vyzo at hackzen.org
Fri Feb 2 06:23:33 EST 2018


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 at iro.umontreal.ca> wrote:

> > On Feb 1, 2018, at 8:06 AM, Dimitris Vyzovitis <vyzo at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20180202/c12fa342/attachment.htm>


More information about the Gambit-list mailing list