[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 10:38:39 EDT 2013


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/84682329/attachment.htm>


More information about the Gambit-list mailing list