[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?
Bradley Lucier
lucier at math.purdue.edu
Thu Jun 20 11:03:13 EDT 2013
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 at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
More information about the Gambit-list
mailing list