The application raised an exception with the message:

[watsy0007]

file-exists?: `exists' access denied for /Applications/Racket v6.1/bin/racket

Stack trace:

find-executable-path at:
  <unknown location>
dll-dir at:
  line 291, column 2, in file /Applications/Racket v6.1/collects/setup/dirs.rkt
<unknown procedure> at:
  line 70, column 15, in file /Applications/Racket v6.1/collects/racket/promise.rkt
call-with-exception-handler at:
  line 264, column 2, in file /Applications/Racket v6.1/collects/racket/private/more-scheme.rkt
<unknown procedure> at:
  line 38, column 2, in file /Applications/Racket v6.1/collects/racket/promise.rkt
get-lib-search-dirs at:
  line 167, column 7, in file /Applications/Racket v6.1/collects/setup/dirs.rkt
so-find at:
  line 28, column 0, in file /Applications/Racket v6.1/collects/racket/private/so-search.rkt
<unknown procedure> at:
  line 83, column 9, in file /Applications/Racket v6.1/collects/racket/runtime-path.rkt
resolve-paths at:
  line 81, column 0, in file /Applications/Racket v6.1/collects/racket/runtime-path.rkt
[running body] at:
  line #f, column #f, in file /Applications/Racket v6.1/share/pkgs/draw-lib/racket/draw/unsafe/glib.rkt
[traversing imports] at:
  line #f, column #f, in file /Applications/Racket v6.1/share/pkgs/draw-lib/racket/draw/unsafe/pango.rkt
[traversing imports] at:
  line #f, column #f, in file /Applications/Racket v6.1/share/pkgs/draw-lib/racket/draw/private/font.rkt
[traversing imports] at:
  line #f, column #f, in file /Applications/Racket v6.1/share/pkgs/draw-lib/racket/draw/private/contract.rkt
[traversing imports] at:
  line #f, column #f, in file /Applications/Racket v6.1/share/pkgs/draw-lib/racket/draw.rkt
[traversing imports] at:
  line #f, column #f, in file /Applications/Racket v6.1/share/pkgs/pict-lib/texpict/mrpict.rkt
[traversing imports] at:
  line #f, column #f, in file /Applications/Racket v6.1/share/pkgs/pict-lib/pict/private/main.rkt
[traversing imports] at:
  line #f, column #f, in file /Applications/Racket v6.1/share/pkgs/pict-lib/pict/main.rkt
[traversing imports] at:
  line #f, column #f, in file program
ns at:
  line 684, column 9, in file /Applications/Racket v6.1/share/pkgs/sandbox-lib/racket/sandbox.rkt
<unknown procedure> at:
  line 698, column 18, in file /Applications/Racket v6.1/share/pkgs/sandbox-lib/racket/sandbox.rkt
call-with-limits at:
  line 379, column 0, in file /Applications/Racket v6.1/share/pkgs/sandbox-lib/racket/sandbox.rkt
evaluate-program at:
  line 675, column 0, in file /Applications/Racket v6.1/share/pkgs/sandbox-lib/racket/sandbox.rkt
call-with-break-parameterization at:
  line 147, column 2, in file /Applications/Racket v6.1/collects/racket/private/more-scheme.rkt
user-process at:
  line 812, column 2, in file /Applications/Racket v6.1/share/pkgs/sandbox-lib/racket/sandbox.rkt

[jarcane]

This is very strange indeed.

I'm getting this same error trying to test on Windows as well, and I previously received by email a report from a user attempting to test it locally on Windows and getting the same error. It doesn't even consistently report the same file path in the error: Once I ran it and it spit out a Racket folder, but on a second occasion it complained of a racket.exe being found in the nVidia PhysX directories. The other user who reported an issue was getting a false positive for a 'racket.exe' living in the Java directories.

Administrator status also does not appear to affect it either.

I shall have to try this under BSD next and see what it does there.

[jarcane]

So after some further checking, I don't have this error on FreeBSD or, naturally, on the try-racket.org server. Presumably this has something to do with Mac and Windows behavior, but damned if I have any guesses as to what.

[samth]

@mflatt might have an idea about what could be different here about find-executable-path on Windows/Mac.

[mflatt]

It's not that find-executable-path is different (it generally won't work in a sandbox), but that it's being called on Mac OS X and Windows. It's called because something is looking for a shared library, and on Mac OS X and Windows, a relative path to check for shared libraries is embedded in the Racket executable.

Around v6.0 or so, I find a lot of problems like this by ensuring that paths are extracted or computed early enough and then cached, but the shared-library path is still a problem (and still on my to-do list). A workaround is to force the calculation and then share the setup/dirs module with a sandbox, as illustrated below.

#lang racket/base
(require racket/sandbox
         setup/dirs)

(find-dll-dir)

(define e (parameterize ([sandbox-namespace-specs
                          (append (sandbox-namespace-specs)
                                  '(setup/dirs))])
            (make-evaluator 'racket/base)))
(e '(require racket/draw))

[jarcane]

Excellent! This does appear to fix the issue on my end. I'll push the change to the repo; let me know if it fixes the Mac version.

[jarcane]

Here's the fix commit. I can confirm that this got it working on Win8.1. https://github.com/jarcane/try-racket/commit/8f0750f0ab22f911f500a6bff8257a5c4e4b673e

[mflatt]

Great!

On further investigation, I see no reason for the default search path for shared libraries to include the DLL/framework path that is embedded in the Racket executable; the normally configured "lib" directory is sufficient. Removing that path lookup solves the sandbox problem for future versions of Racket.

[jarcane]

Hmm. It seems this fix gets the code running, but does odd things to the exception handling on the sandbox. Now instead of a proper stack trace like I'd expect from the version currently running on the server, I get a similar error again but followed by the actual error. e.g.

> (don-t-crash)
exception raised by error display handler; directory-exists?: `exists' access denied for c:\; original exception raised: don-t-crash: undefined;
 cannot reference an identifier before its definition