<div>That's right, not documented.</div><div><br></div>You mean documented as in in the Gambit manual, or documented as in a comment provided at their location in Gambit's sources?<br><br><div class="gmail_quote">2013/6/20 Bradley Lucier <span dir="ltr"><<a href="mailto:lucier@math.purdue.edu" target="_blank">lucier@math.purdue.edu</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>


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