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

From: Greg Hendershott (greghendershott at gmail.com)
Date: Mon Jul 11 16:43:24 EDT 2011

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
>



Posted on the users mailing list.