<div>Dear Marc,</div><div><br></div><div>Soo I've hunted this memory leak down a bit now and I'm starting to feel I got somewhere:</div><div><br></div><div>So basically I noted that my heap was filling up with a vector object that I use for IO.</div>

<div><br></div><div>Now analyzed what references it using ##resolve-referencing-objects .</div><div><br></div><div><br></div><div><div>This memory leak seems to happen for something-like-in-the-range every 10:th incoming TCP connection.</div>

<div><br></div><div>It's handled by Sack, and then as we see left on the heap are some structures regarding its I/O.</div></div><div><br></div><div>This is a bit funny as I have the impression that Sack can run without producing any memory leaks too.</div>

<div><br></div><div><br></div><div>Here's the tracing of the root for such a vector:</div><div><br></div><div><br></div><div><br></div><div><br></div><div>A stack frame is referencing it, which is of a procedure that I provide, whose invocation ended long ago.</div>

<div><br></div><div>That stack frame in turn is referenced by the procedure that created the vector.</div><div><br></div><div><br></div><div><br></div><div>And that stack frame in turn is referenced by ##read-u8 (!)</div>

<div><br></div><div>And that stack frame in turn is referenced by ##byte-rbuf-fill (!)</div><div><br></div><div>And that stack frame in turn is referenced by ##wait-for-io! (!)</div><div><br></div><div>And that stack frame in turn is referenced by ##thread-interrupt! (!)</div>

<div><br></div><div>And that stack frame in turn is referenced by ##thread-call (!)</div><div><br></div><div><br></div><div>And that stack frame in turn is referenced by a continuation object.</div><div><br></div><div>The continuation object's denv is</div>

<div><br></div><div>#(#((#<procedure #N current-directory> . "/home/USER/") () ())</div><div>  #(0)</div><div>  0</div><div>  0</div><div>  (#<procedure #N current-exception-handler> . #<procedure #N primordial-exception-handler>)</div>

<div>  (#<procedure #N current-input-port> . #<input-output-port #N dummy>)</div><div>  (#<procedure #N current-output-port> . #<input-output-port #N dummy>)</div><div>  (#f . #f))</div><div><br></div>

<div><br></div><div><br></div><div>That continuation object in turn is referenced by</div><div><br></div><div> * A mutex with the mutex-name 'thread-call-result ,</div><div><br></div><div>   mutex-state #<thread #1 primordial>  ,</div>

<div><br></div><div>   mutex-specific set to the continuation itself.</div><div><br></div><div> * This vector #(3 2 #<continuation #N> #!unbound) - I think that's a product of the evaluator</div><div><br></div>
<div>
 * (#<continuation #N>)</div><div><br></div><div> * (#<continuation #N> . #t)</div><div><br></div><div><br></div><div><br></div><div>The mutex is in turn referenced by another three mutexes, each being a 'thread-call-result mutex</div>

<div>with another continuation as its specific.</div><div><br></div><div><br></div><div><br></div><div><br></div><div>If there's anything more that's relevant for me to check here, feel free to let me know.</div>
<div>
<br></div><div><br></div><div><br></div><div>Do you see any plausible reason for the leak?</div><div><br></div><div><br></div><div>Best regards,</div><div>Mikael</div><div><br></div>