[racket] Amazon Linux update causes `require' in 5.1.1 to hang indefinitely?

> It might be one of these things that prevent data execution.  With the
> jit on, Racket is basically throwing some numbers into memory and then
> executes them -- which is a power that some people don't like.  It
> (Racket) does do the right thing an marks those memory pages as
> executable, but it looks like something on your system is preventing
> it somehow, possibly leading to that block.

Can you mention some examples of things on Linux that might prevent it?

(This same system was able to run Racket JIT just fine before. I've
spent hours thinking and exploring, and I'm stumped trying to identify
what could have changed and what's going on.)


BTW, the simplest recipe I've found is extremely simple:

$ unset PLTNOMZJIT  # make sure JIT is enabled
$ strace ./req-no-exist.rkt

where req-no-exist.rkt is simply

#! /usr/bin/racket
#lang racket
(require no-exist) ; no-exist doesn't exist in any collection

What happens is that Racket prints the error message that the it
doesn't exist ... and then it "hangs" consuming 99% CPU.

The last lines of the strace are:

stat64("/home/ec2-user/src/scheme/no-exist", 0xbf9aafc4) = -1 ENOENT (No such f\
ile or directory)
stat64("/home/ec2-user/.racket/5.1.1/collects/no-exist", 0xbf9aafc4) = -1 ENOEN\
T (No such file or directory)
stat64("/usr/racket/collects/no-exist", 0xbf9aafc4) = -1 ENOENT (No such file o\
r directory)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
mprotect(0xb5944000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0x4)                       = -1235663784
futex(0x93e08cc, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x93e08c8, {FUTEX_OP_SET, 0, FUTE\
X_OP_CMP_GT, 1}) = 1
futex(0x93e08b0, FUTEX_WAKE_PRIVATE, 1) = 1
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
mprotect(0xb6678000, 16384, PROT_READ|PROT_WRITE) = 0
rt_sigreturn(0xfffffa54)                = -1234715688
fcntl64(2, F_GETFL)                     = 0x8002 (flags O_RDWR|O_LARGEFILE)
fcntl64(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
write(2, "req-no-exist.rkt:4:9: no-exist: "..., 230req-no-exist.rkt:4:9: no-exi\
st: 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) = 230
fcntl64(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0
fcntl64(2, F_GETFL)                     = 0x8002 (flags O_RDWR|O_LARGEFILE)
fcntl64(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
write(2, "\n", 1
)                       = 1
fcntl64(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0
fcntl64(2, F_GETFL)                     = 0x8002 (flags O_RDWR|O_LARGEFILE)
fcntl64(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
write(2, "\n === context ===\n", 18
 === context ===
)    = 18
fcntl64(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0
fcntl64(2, F_GETFL)                     = 0x8002 (flags O_RDWR|O_LARGEFILE)
fcntl64(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
write(2, "standard-module-name-resolver", 29standard-module-name-resolver) = 29
fcntl64(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0
fcntl64(2, F_GETFL)                     = 0x8002 (flags O_RDWR|O_LARGEFILE)
fcntl64(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
write(2, "\n", 1
)                       = 1
fcntl64(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0
fcntl64(2, F_GETFL)                     = 0x8002 (flags O_RDWR|O_LARGEFILE)
fcntl64(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
write(2, "standard-module-name-resolver", 29standard-module-name-resolver) = 29
fcntl64(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0
fcntl64(2, F_GETFL)                     = 0x8002 (flags O_RDWR|O_LARGEFILE)
fcntl64(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
write(2, "\n", 1
)                       = 1
fcntl64(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0
fcntl64(2, F_GETFL)                     = 0x8002 (flags O_RDWR|O_LARGEFILE)
fcntl64(2, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
write(2, "\n", 1
)                       = 1
fcntl64(2, F_SETFL, O_RDWR|O_LARGEFILE) = 0



On Mon, Jul 11, 2011 at 10:46 PM, Eli Barzilay <eli at 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.  With the
> jit on, Racket is basically throwing some numbers into memory and then
> executes them -- which is a power that some people don't like.  It
> (Racket) does do the right thing an marks those memory pages as
> executable, but it looks like something on your system is preventing
> it somehow, possibly leading to that block.
>
> --
>          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                    http://barzilay.org/                   Maze is Life!
>