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

I've discovered that the problem does NOT happen if I start racket
with -j a.k.a. --no-jit.

?

On Mon, Jul 11, 2011 at 4:43 PM, Greg Hendershott
<greghendershott at gmail.com> wrote:
> I have an strace but it's 6,000 lines long and I'm not sure how to interpret it.
>
> The tail of it is:
>
> mprotect(0xb5e60000, 16384, PROT_READ|PROT_WRITE) = 0
> rt_sigreturn(0xfffffa54)                = -1257770392
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> mprotect(0xb51e0000, 16384, PROT_READ|PROT_WRITE) = 0
> rt_sigreturn(0xb73b0e04)                = -1257765432
> futex(0x8cf28cc, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x8cf28c8, {FUTEX_OP_SET, 0, FUTE\
> X_OP_CMP_GT, 1}) = 1
> futex(0x8cf28b0, FUTEX_WAKE_PRIVATE, 1) = 1
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1\
> , 0) = 0xa46000
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> mprotect(0xb5ef8000, 16384, PROT_READ|PROT_WRITE) = 0
> rt_sigreturn(0xfffffa54)                = -1257624456
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1\
> , 0) = 0x7bd000
> mmap2(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1\
> , 0) = 0x92a000
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> mprotect(0xb60e0000, 16384, PROT_READ|PROT_WRITE) = 0
> rt_sigreturn(0xbfcb734c)                = -1240584328
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1\
> , 0) = 0xdf3000
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1\
> , 0) = 0x92c000
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> mprotect(0xb60f0000, 16384, PROT_READ|PROT_WRITE) = 0
> rt_sigreturn(0xb60f0a20)                = -1257597536
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> mprotect(0xb60e8000, 16384, PROT_READ|PROT_WRITE) = 0
> rt_sigreturn(0xbfcb730c)                = -1240559224
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1\
> , 0) = 0x189000
> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
> mprotect(0xb60f8000, 16384, PROT_READ|PROT_WRITE) = 0
> rt_sigreturn(0xfffffa54)                = -1257591496
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1\
> , 0) = 0xb49000
> stat64("/home/ec2-user/perl5/bin/racket", 0xbfcb6d2c) = -1 ENOENT (No such file\
>  or directory)
> stat64("/usr/local/bin/racket", 0xbfcb6d2c) = -1 ENOENT (No such file or direct\
> ory)
> stat64("/bin/racket", 0xbfcb6d2c)       = -1 ENOENT (No such file or directory)
> stat64("/usr/bin/racket", {st_mode=S_IFREG|0775, st_size=2561109, ...}) = 0
> readlink("/usr/bin/racket", "/usr/racket/bin/racket", 2048) = 22
> readlink("/usr/racket/bin/racket", 0xbfcb6568, 2048) = -1 EINVAL (Invalid argum\
> ent)
> stat64("/usr/racket/bin/../collects", {st_mode=S_IFDIR|0775, st_size=4096, ...}\
> ) = 0
> readlink("/usr/racket/bin", 0xbfcb6478, 2048) = -1 EINVAL (Invalid argument)
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1\
> , 0) = 0x4a8000
>
> Does this mean it's hung trying to read /usr/bin/racket ?
>
> To make it more confusing, I spooled up a fresh instance based on a
> snapshot of the pre-yum-update image, and now the problem is happening
> with that, too.  Apparently it wasn't due to say yum pulling a new
> glibc or something like that.
>
> Plus as I've experimented more, I'm finding that a `require' of
> certain modules hangs, but others is OK. I haven't been able to narrow
> it down so far. My only tentative conclusion is that it only hangs if
> I require modules in my own collection .. but not always then.  i.e.
> Requiring from my own collection seems necessary but not sufficient.
>
> On Mon, Jul 11, 2011 at 12:41 PM, Jon Rafkind <rafkind at cs.utah.edu> wrote:
>> Maybe you can run 'strace' on racket to see if its hanging on a file?
>>
>> On 07/11/2011 10:34 AM, Greg Hendershott wrote:
>>> I'm trying that now (first time ever).
>>>
>>> Unfortunately the make is stuck at the last line for 10+ minutes, with
>>> `top' showing xform.rkt pegged at 99% CPU.
>>>
>>> Make output:
>>>
>>> ...
>>> ranlib libracket.a
>>> make[5]: Leaving directory
>>> `/home/ec2-user/misc/racket-source/racket-5.1.1/src/build/racket'
>>> make[4]: Leaving directory
>>> `/home/ec2-user/misc/racket-source/racket-5.1.1/src/build/racket'
>>> make racketcgc
>>> make[4]: Entering directory
>>> `/home/ec2-user/misc/racket-source/racket-5.1.1/src/build/racket'
>>> gcc -I. -I../../racket/include -g -O2  -Wall  -pthread
>>> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>>> -DINITIAL_COLLECTS_DIRECTORY='"'"`cd ../../racket/../../collects;
>>> pwd`"'"' -c ../../racket/main.c -o main.o
>>> gcc -o racketcgc main.o  libracket.a libmzgc.a  -pthread -ldl -lm
>>> -ldl -lm -rdynamic
>>> make[4]: Leaving directory
>>> `/home/ec2-user/misc/racket-source/racket-5.1.1/src/build/racket'
>>> make[3]: Leaving directory
>>> `/home/ec2-user/misc/racket-source/racket-5.1.1/src/build/racket'
>>> cd gc2; make all
>>> make[3]: Entering directory
>>> `/home/ec2-user/misc/racket-source/racket-5.1.1/src/build/racket/gc2'
>>> mkdir xsrc
>>> make xsrc/precomp.h
>>> make[4]: Entering directory
>>> `/home/ec2-user/misc/racket-source/racket-5.1.1/src/build/racket/gc2'
>>> env XFORM_PRECOMP=yes ../racketcgc -cqu ../../../racket/gc2/xform.rkt
>>> --setup . --cpp "gcc -E -I./.. -I../../../racket/gc2/../include
>>> -pthread   -DNEWGC_BTC_ACCOUNT  -D_LARGEFILE_SOURCE
>>> -D_FILE_OFFSET_BITS=64 "  --keep-lines -o xsrc/precomp.h
>>> ../../../racket/gc2/precomp.c
>>>
>>> Meanwhile `top' shows xform.rkt pegged at 99% CPU.
>>>
>>> So seemingly the build of Racket involves running Racket, and is
>>> encountering the original problem I had? Presumably xform.rkt has a
>>> `require' early on?
>>>
>>> On Mon, Jul 11, 2011 at 12:02 PM, Noel Welsh <noelwelsh at gmail.com> wrote:
>>>> No idea here, but why not try compiling Racket from source?  All you
>>>> need is ./configure ; make ; make install
>>>>
>>>> HTH,
>>>> N.
>>>>
>>>> On Mon, Jul 11, 2011 at 4:45 PM, Greg Hendershott
>>>> <greghendershott at gmail.com> wrote:
>>>>> Yesterday I ran `yum update' on an Amazon Linux 32-bit instance. It
>>>>> updated quite a bit more than I expected.
>>> _________________________________________________
>>>   For list-related administrative tasks:
>>>   http://lists.racket-lang.org/listinfo/users
>>
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/users
>>
>