> I'd guess it's the what the jit is compiling to as opposed to the > memory manipulations themselves that is causing it to spin.
Ah, I see what you mean. In fact that's evident from the "context" for the error message, which differs for JIT on or off: ===[ JIT off ]=========================================== $ export PLTNOMZJIT=1 $ ./req-no-exist.rkt req-no-exist.rkt:4:9: no-exist: standard-module-name-resolver: collection not found: "no-exist" in any of: (#<path:/home/ec2-user/src/scheme> #<path:/home/ec2-user/.racket/5.1.1/collects> #<path:/usr/racket/collects>) in: no-exist === context === show-collection-err $ ### terminated normally ===[ JIT on ]============================================ $ unset PLTNOMZJIT $ ./req-no-exist.rkt req-no-exist.rkt:4:9: no-exist: standard-module-name-resolver: collection not found: "no-exist" in any of: (#<path:/home/ec2-user/src/scheme> #<path:/home/ec2-user/.racket/5.1.1/collects> #<path:/usr/racket/collects>) in: no-exist === context === standard-module-name-resolver standard-module-name-resolver ### "hung" bogarting the CPU ========================================================= On Tue, Jul 12, 2011 at 12:20 PM, Ray Racine <ray.rac...@gmail.com> wrote: > On Mon, Jul 11, 2011 at 10:46 PM, Eli Barzilay <e...@barzilay.org> wrote: >> >> An hour and a half ago, Greg Hendershott wrote: >> > I've discovered that the problem does NOT happen if I start racket >> > with -j a.k.a. --no-jit. >> > >> > ? >> >> It might be one of these things that prevent data execution. > > I helped debug that on the 64 bit build when the jit first rolled out. No > jit fine, with jit you got a clear segfault if the proper mprotect is not > set. I'd guess it's the what the jit is compiling to as opposed to the > memory manipulations themselves that is causing it to spin. > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
