[gambit-list] Progress with the memory leak hunting, the root reference is a 'thread-call-result mutex referencing a continuation starting w ##thread-call . What this means?

Mikael mikael.rcv at gmail.com
Thu Jun 20 11:04:35 EDT 2013


That's right, not documented.

You mean documented as in in the Gambit manual, or documented as in a
comment provided at their location in Gambit's sources?

2013/6/20 Bradley Lucier <lucier at math.purdue.edu>

> If, perchance, any of the routines you are discovering are not documented,
> perhaps you could document each of them a bit and send a pull request to
> Marc.
>
> Brad
>
> On Jun 20, 2013, at 10:38 AM, Mikael wrote:
>
> > Dear Marc,
> >
> > Soo I've hunted this memory leak down a bit now and I'm starting to feel
> I got somewhere:
> >
> > So basically I noted that my heap was filling up with a vector object
> that I use for IO.
> >
> > Now analyzed what references it using ##resolve-referencing-objects .
> >
> >
> > This memory leak seems to happen for something-like-in-the-range every
> 10:th incoming TCP connection.
> >
> > It's handled by Sack, and then as we see left on the heap are some
> structures regarding its I/O.
> >
> > This is a bit funny as I have the impression that Sack can run without
> producing any memory leaks too.
> >
> >
> > Here's the tracing of the root for such a vector:
> >
> >
> >
> >
> > A stack frame is referencing it, which is of a procedure that I provide,
> whose invocation ended long ago.
> >
> > That stack frame in turn is referenced by the procedure that created the
> vector.
> >
> >
> >
> > And that stack frame in turn is referenced by ##read-u8 (!)
> >
> > And that stack frame in turn is referenced by ##byte-rbuf-fill (!)
> >
> > And that stack frame in turn is referenced by ##wait-for-io! (!)
> >
> > And that stack frame in turn is referenced by ##thread-interrupt! (!)
> >
> > And that stack frame in turn is referenced by ##thread-call (!)
> >
> >
> > And that stack frame in turn is referenced by a continuation object.
> >
> > The continuation object's denv is
> >
> > #(#((#<procedure #N current-directory> . "/home/USER/") () ())
> >   #(0)
> >   0
> >   0
> >   (#<procedure #N current-exception-handler> . #<procedure #N
> primordial-exception-handler>)
> >   (#<procedure #N current-input-port> . #<input-output-port #N dummy>)
> >   (#<procedure #N current-output-port> . #<input-output-port #N dummy>)
> >   (#f . #f))
> >
> >
> >
> > That continuation object in turn is referenced by
> >
> >  * A mutex with the mutex-name 'thread-call-result ,
> >
> >    mutex-state #<thread #1 primordial>  ,
> >
> >    mutex-specific set to the continuation itself.
> >
> >  * This vector #(3 2 #<continuation #N> #!unbound) - I think that's a
> product of the evaluator
> >
> >  * (#<continuation #N>)
> >
> >  * (#<continuation #N> . #t)
> >
> >
> >
> > The mutex is in turn referenced by another three mutexes, each being a
> 'thread-call-result mutex
> > with another continuation as its specific.
> >
> >
> >
> >
> > If there's anything more that's relevant for me to check here, feel free
> to let me know.
> >
> >
> >
> > Do you see any plausible reason for the leak?
> >
> >
> > Best regards,
> > Mikael
> >
> > _______________________________________________
> > Gambit-list mailing list
> > Gambit-list at iro.umontreal.ca
> > https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20130620/19dfe4eb/attachment.htm>


More information about the Gambit-list mailing list