[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 14:31:59 EDT 2013


I've gotten to a point where my best understanding is that this memory leak
problem consists of:

When an IO timeout exception happens, the thread is removed from any thread
groups so its execution is halted, but a memory reference is left to it on
the heap.

This is what seems to be going on here.

The stack frame analysis I made in the previous commit, essentially shows
Sack's ordinary calling of ##read-u8 to read a HTTP header, and IO timeout
here is the ordinary exit path.

I'll try to reduce the error and to quantify its occurrence more.

Mikael


2013/6/20 Mikael <mikael.rcv at gmail.com>

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20130620/97dac8df/attachment.htm>


More information about the Gambit-list mailing list