[racket] Getting unusual behavior from racket/sandbox: not truly capping memory usage?!

And I've verified that the memory leak goes away in the Web server use case

Jay

On Mon, Apr 22, 2013 at 4:32 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> Yes, it was a bug in the implementation of NACK evts.
>
> The following program illustrates a problem, where a NACK becomes
> ready even though its event was previously selected by `sync':
>
>  #lang racket
>  (thread
>   (lambda ()
>     (sync (nack-guard-evt
>            (lambda (nack)
>              (thread (lambda ()
>                        (sync nack)
>                        (error "wrong!")))
>              always-evt)))))
>  (sync (system-idle-evt))
>
> The memory leak is a reflection of this NACK bug; a thread that is
> blocked on a NACK and should be GCed along with the NACK was sticking
> around --- because the thread actually can run when some other thread
> (the one representing the connection in the original example)
> terminates.
>
> I've pushed a repair.
>
> Thanks, Danny and Jay, for narrowing down the problem!
>
> At Mon, 22 Apr 2013 14:31:52 -0600, Danny Yoo wrote:
>> Ok, good!  Matthew Flatt is investigating.
>>
>> It looks like something like:
>>
>>
>> https://github.com/dyoo/racket/commit/6547d18c006e7390c3cbce84a93dd9d9c926341b
>>
>> can clear the memory leak, but mflatt says that we shouldn't have to
>> do this, that the VM should automatically kill the monitoring thread
>> once it detects the nack is inaccessible.  This is totally out of my
>> domain, but thankfully he's on it now.  :)
>> ____________________
>>   Racket Users list:
>>   http://lists.racket-lang.org/users



-- 
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93