[racket-dev] sporadic failure when building PLaneT docs

From: Eli Barzilay (eli at barzilay.org)
Date: Fri Aug 19 23:28:04 EDT 2011

9 minutes ago, Robby Findler wrote:
> On Fri, Aug 19, 2011 at 12:50 PM, Eli Barzilay <eli at barzilay.org> wrote:
> > Three hours ago, Robby Findler wrote:
> >>
> >> Maybe Eli can say more?
> >
> > I have no idea what the problem is, or how to get it without involving
> > planet.
> 
> I don't see why that should stop you.
> 
> To spur you along, I've noticed that the sandbox creates a module with
> the name 'program from the use-lang function on line 518 which seems
> to be making its way over to the argument to evaluate-program (line
> 564) and from there the module is required but without, apparently,
> ever evaluating the module (or maybe evaluating it in a different
> namespace).
> 
> This sure seems like something that someone who is familiar with how
> the sandbox code works could shed some light on. I tried working
> through the code a little bit this evening but find it difficult to
> read.

I still don't know what "this" is referring to, besides some getting
some vague idea that Danny's code has some problem.


> For example, I think code like this:
> 
>   (when ns (set! ns (ns)))
> 
> is bad style; when you're using "ns" for a variable to stand for
> "namespace" you should probably make sure it is bound to a
> namespace, or use something else. Also, it seems unwise to add that
> kind of imperative dependency to reasoning about what is going on
> with 'ns' and when it is (may be) created. I would have used two
> variables.
> 
> I'll also note that this line seems like it can lead to a bug
> because shortly thereafter I see this:
> 
>   (when ns (current-namespace ns))

That's something local to that code, basically:

  (let ([ns (if something (lambda () compute-some-namespace) #f)])
    ...
    (when ns (set! ns (ns)))
    ...
    (when ns (current-namespace ns)))


> which looks like it can fail in the case that the limit-thunk does
> something to above the computation that does the set!.

I'll add the condition, but it's not a problem since the code that
I've seen used a trusted sandbox, which means that `limit-thunk' is
not doing anything.  (BTW, it's also not a problem in general, since
`limit-thunk' can throw an error and kill the whole call.)


> I can't tell for sure if this can happen because I got lost in the
> call-with-limits.
> 
> I did notice that call-with-limits has this
> 
>   (let ([r #f])
>     ..stuff..
>     (define r ...)
>      ...use r ...)
> 
> in such a way that the outer binding of 'r' is never used which seems
> a little suspicious. At a min, that unused binding probably be
> removed, but maybe there is an actual bug there and those two 'r's are
> supposed to not shadow each other?

I'll look at that too, but again, with a trusted sandbox, it's all
irrelevant to whatever problem Danny's having.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!


Posted on the dev mailing list.