[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