[gambit-list] Dumping the heap
vyzo at hackzen.org
Fri Feb 2 06:23:33 EST 2018
Relevant code for accounting still objects:
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?
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gambit-list