Well, I meant a few lines in the sources, to document the internals.

Brad

On Jun 20, 2013, at 11:04 AM, Mikael wrote:

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@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@iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list