There is also the 6.4 Undocumented extensions section in the Gambit manual that is there for this purpose, correct me if I'm wrong Marc.

On Thu, Jun 20, 2013 at 11:10 AM, Bradley Lucier <lucier@math.purdue.edu> wrote:
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




_______________________________________________
Gambit-list mailing list
Gambit-list@iro.umontreal.ca
https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list