[racket-dev] call-with-limits memory bound isn't actually bounding memory usage

What does it mean to "refer to module A in racket/load"?

I think maybe there's some confusion about what role namespaces play and
how they work in Racket? I will try to explain. The basic idea is that a
namespace is a table mapping module names ("A" in this example) to actual
modules (it also maps top-level variables, but you don't want to really be
outside of modules (which is where those variables are) if you can help it
anyways, so lets ignore that). So, when you write

  (parameterize ([current-namespace (make-base-namespace)])
    ....)

around some expression, then calls to things that check the namespace (eg,
dynamic-require, evaluating module expressions) will now refer to that
newly created namespace.

So, if you want to be able to refer to the module "A" in that new
namespace, you have to get it into that new namespace, either by 'eval'ing
the definition, or by putting it into a file and namespace-require'ing that
file, or something along those lines.

But returning to your earlier questions: have you tried to read the
custodian-memory-limit docs and the ISMM paper about it? If not, reading
that and asking questions about it is probably a good next step.

Robby



On Wed, Sep 11, 2013 at 2:59 PM, J. Ian Johnson <ianj at ccs.neu.edu> wrote:

> Okay, stamourv made your response make sense. I added parameterize
> ([current-namespace (make-base-namespace)]) inside the thunk, and it works.
> Albeit ''A was no longer a valid module path in #lang racket/load, it works
> for files.
> What is the right way to refer to module A in racket/load, though?
>
> Thanks,
> -Ian
> ----- Original Message -----
> From: "J. Ian Johnson" <ianj at ccs.neu.edu>
> To: "Robby Findler" <robby at eecs.northwestern.edu>
> Cc: "dev" <dev at racket-lang.org>, "J. Ian Johnson" <ianj at ccs.neu.edu>
> Sent: Wednesday, September 11, 2013 3:49:50 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] call-with-limits memory bound isn't actually
> bounding memory usage
>
> Just so we're clear, this should not OOM, but rather print #t?
>
> #lang racket/load
>
> (module A racket
>  (provide global go)
>  (define global '())
>  (define (go) (set! global (cons (random) global)) (go)))
>
> (module B racket
>   (require racket/sandbox)
>   (display
>    (with-handlers ([exn:fail:resource? (λ (e)
>                                           (case
> (exn:fail:resource-resource e)
>                                             [(memory) #t]
>                                             [else #f]))])
>      (call-with-limits 10000 512 (λ () ((dynamic-require ''A 'go)))))))
>
> (require 'B)
>
> -Ian
> ----- Original Message -----
> From: "Robby Findler" <robby at eecs.northwestern.edu>
> To: "J. Ian Johnson" <ianj at ccs.neu.edu>
> Cc: "dev" <dev at racket-lang.org>
> Sent: Wednesday, September 11, 2013 3:34:55 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] call-with-limits memory bound isn't actually
> bounding memory usage
>
>
> The namespace...?
>
>
>
> On Wed, Sep 11, 2013 at 2:20 PM, J. Ian Johnson < ianj at ccs.neu.edu >
> wrote:
>
>
> I've since changed to using a dynamic-require, but still the memory limit
> is not respected. Why wouldn the globals from a dynamic-require be
> considered reachable outside the sandbox that calls dynamic-require?
> There's no other way to get it.
>
> -Ian
> ----- Original Message -----
>
>
> From: "J. Ian Johnson" < ianj at ccs.neu.edu >
> To: "David Vanderson" < david.vanderson at gmail.com >
> Cc: "dev" < dev at racket-lang.org >, "J. Ian Johnson" < ianj at ccs.neu.edu >
> Sent: Monday, September 9, 2013 2:01:02 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] call-with-limits memory bound isn't actually
> bounding memory usage
>
> Ah, that would probably be the problem. Without having to modify too much
> code, would the proper way to call a function entirely within the sandbox
> be to use dynamic-require in the thunk, rather than require in the module
> using call-with-limits?
> -Ian
> ----- Original Message -----
> From: "David Vanderson" < david.vanderson at gmail.com >
> To: "J. Ian Johnson" < ianj at ccs.neu.edu >
> Cc: "dev" < dev at racket-lang.org >
> Sent: Monday, September 9, 2013 1:50:13 PM GMT -05:00 US/Canada Eastern
> Subject: Re: [racket-dev] call-with-limits memory bound isn't actually
> bounding memory usage
>
> Just to make sure, is the memory being allocated reachable from outside
> the sandbox?
>
> http://www.cs.utah.edu/plt/publications/ismm04-addendum.txt
>
> On 09/09/2013 01:29 PM, J. Ian Johnson wrote:
> > I don't use the gui framework at all. This is all just pounding on
> global hash-tables and vectors. Or are you talking about the sandbox
> queuing up callbacks?
> > -Ian
> > ----- Original Message -----
> > From: "Robby Findler" < robby at eecs.northwestern.edu >
> > To: "J. Ian Johnson" < ianj at ccs.neu.edu >
> > Cc: "dev" < dev at racket-lang.org >
> > Sent: Monday, September 9, 2013 1:16:51 PM GMT -05:00 US/Canada Eastern
> > Subject: Re: [racket-dev] call-with-limits memory bound isn't actually
> bounding memory usage
> >
> >
> > The framework will, sometimes do stuff that queues callbacks and,
> depending on how you've set up other things, the code running there might
> escape from the limit. Did you try putting the eventspace under the limit
> too?
> >
> > Robby
> >
> >
> >
> > On Mon, Sep 9, 2013 at 10:54 AM, J. Ian Johnson < ianj at ccs.neu.edu >
> wrote:
> >
> >
> > I'm running my analysis benchmarks in the context of (with-limits (* 30
> 60) 2048 <run-analysis>), and it's been good at killing the process when
> the run should time out, but now I have an instantiation of the framework
> that just gobbles up 15GiB of memory without getting killed. What might be
> going on here?
> >
> > Running 5.90.0.9
> > -Ian
> > _________________________
> > Racket Developers list:
> > http://lists.racket-lang.org/dev
> >
> > _________________________
> > Racket Developers list:
> > http://lists.racket-lang.org/dev
> >
>
> _________________________
> Racket Developers list:
> http://lists.racket-lang.org/dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130911/99b7e899/attachment.html>