[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?

Guillaume Cartier gcartier at jazzscheme.org
Thu Jun 20 13:09:49 EDT 2013


There is also the 6.4 Undocumented extensions section in the Gambit manual
that is there for this purpose, correct me if I'm wrong Marc.

On Thu, Jun 20, 2013 at 11:10 AM, Bradley Lucier <lucier at math.purdue.edu>wrote:

> Well, I meant a few lines in the sources, to document the internals.
>
> Brad
>
> On Jun 20, 2013, at 11:04 AM, Mikael wrote:
>
> That's right, not documented.
>
> You mean documented as in in the Gambit manual, or documented as in a
> comment provided at their location in Gambit's sources?
>
> 2013/6/20 Bradley Lucier <lucier at math.purdue.edu>
>
>> 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
>>
>>
>
>
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20130620/d9ef546a/attachment.htm>


More information about the Gambit-list mailing list