Bug #10438
closedminiruby hangs on Mac 10.8.5 during build of ruby 2.1.4
Description
I am trying to make ruby 2.1.4 on a Mac 10.8.5 and the call to miniruby to update rbconfig.rb hangs.
When I attach to the process using gdb, the stack is:
(gdb) where
#0 st_update (key=140492321470720, table=0x7fc6e9409bd0, func=0x7fc6e98eb498, arg=140492298695832) at st.c:387
#1 0x000000010e5847fc in rb_fstring (str=140492321470720) at string.c:212
#2 0x000000010e52a8a0 in register_symid_str (id=13360, str=140492321470720) at parse.y:10373
#3 0x000000010e52c1b9 in rb_intern3 (name=0x10e609958 "mesg", len=4, enc=0x7fc6e9409410) at parse.y:10429
#4 0x000000010e5b97e5 in rb_iv_set (obj=140492321470760, name=0x0, val=140492321470800) at variable.c:2611
#5 0x000000010e4b7c61 in exc_initialize (argc=Cannot access memory at address 0x0
) at error.c:605
#6 0x000000010e5d5a17 in call_cfunc_m1 (func=0x376a8b96ed956ed2, recv=4535727376, argc=0, argv=0x7fc6eaea3900) at vm_insnhelper.c:1317
#7 0x000000010e5df746 in vm_call0_cfunc_with_frame [inlined] () at vm_eval.c:118
#8 vm_call0_cfunc [inlined] () at /usr/local/prvm/ruby-2.1.4/src/ruby-2.1.4/vm_eval.c:135
#9 0x000000010e5df746 in vm_call0 (th=0x7fc6e98eb728, recv=140492321470720, id=4535727376, argc=-376523608, argv=0x7fc6e98eb728, me=0x7fc6e94241e0, defined_class=140492297897720) at vm_eval.c:175
#10 0x000000010e5ebb9d in rb_call0 (recv=Cannot access memory at address 0x0
) at vm_eval.c:325
#11 0x000000010e5129fc in rb_class_new_instance (argc=-353748696, argv=0xe98eb97800000001, klass=140492293566576) at object.c:1860
#12 0x000000010e5d5a17 in call_cfunc_m1 (func=0x7fc6e9828270, recv=16829592782577336321, argc=-381652880, argv=0x7fc6eaea3928) at vm_insnhelper.c:1317
#13 0x000000010e5df746 in vm_call0_cfunc_with_frame [inlined] () at vm_eval.c:118
#14 vm_call0_cfunc [inlined] () at /usr/local/prvm/ruby-2.1.4/src/ruby-2.1.4/vm_eval.c:135
#15 0x000000010e5df746 in vm_call0 (th=0x7fc6e98eb958, recv=140492321470760, id=16829592782577336321, argc=-376522376, argv=0x7fc6e98eb958, me=0x7fc6e94144d0, defined_class=140492297910000) at vm_eval.c:175
#16 0x000000010e5e90c4 in rb_funcall (recv=140492298697368, mid=140492298697368, n=1) at vm_eval.c:325
#17 0x000000010e4b8da8 in rb_exc_new_str (str=140492321470800, etype=140492297896560) at error.c:588
#18 0x000000010e5dbb83 in rb_arg_error_new [inlined] () at /usr/local/prvm/ruby-2.1.4/src/ruby-2.1.4/vm_insnhelper.c:122
#19 0x000000010e5dbb83 in rb_error_arity (argc=-353748656, min=-353748656, max=3272) at vm_insnhelper.c:151
#20 0x000000010e4bce55 in make_exception (argc=-377322896, argv=0x6, isstr=3272) at intern.h:301
#21 0x00007fc6eaea39a0 in ?? ()
#22 0x000000010e4bcf06 in rb_exc_raise (mesg=140492321470880) at eval.c:572
#23 0x000000010e5dbb8b in rb_error_arity (argc=<value temporarily unavailable, due to optimizations>, min=<value temporarily unavailable, due to optimizations>, max=<value temporarily unavailable, due to optimizations>) at vm_insnhelper.c:151
#24 0x000000010e4bce55 in make_exception (argc=-353748576, argv=0x6, isstr=3272) at intern.h:301
#25 0x00007fc6eaea3a18 in ?? ()
gdb then produces an infinite stack until gdb core dumps (which I assume is a bug in gdb)
Other data:
st_update (key=140719613688080, table=0x7ffbd3409bf0, func=0x7ffbd38eb498, arg=140719562863768) at st.c:387
387 while (PTR_NOT_EQUAL(table, ptr->next, hash_val, key)) {
(gdb) print ptr
$1 = (st_table_entry *) 0x1078a5e55
(gdb) print *ptr
$2 = {
hash = 10036285496377639745,
key = 17229058033700311155,
record = 6647695647989104639,
next = 0xf66c35d5f415e41,
fore = 0x801f0f0000441f,
back = 0xbae5894855000000
}
(gdb) print ptr->next
$3 = (st_table_entry *) 0xf66c35d5f415e41
(gdb) print ptr->next->next
Cannot access memory at address 0xf66c35d5f415e59
(gdb) print *ptr->next
Cannot access memory at address 0xf66c35d5f415e41
(gdb) print *ptr
$4 = {
hash = 10036285496377639745,
key = 17229058033700311155,
record = 6647695647989104639,
next = 0xf66c35d5f415e41,
fore = 0x801f0f0000441f,
back = 0xbae5894855000000
}
address 0xf66c35d5f415e41 appears to be invalid.
gcc-4.2 --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Updated by nagachika (Tomoyuki Chikanaga) about 10 years ago
- Backport changed from 2.0.0: UNKNOWN, 2.1: UNKNOWN to 2.0.0: UNKNOWN, 2.1: REQUIRED
Hello, Perry.
Thank you for your report.
This could be related with homebrew apple-gcc42 thing.
Please try configure with --gcc=/usr/bin/gcc or --gcc=/usr/bin/clang.
if it works, r48174 seems fixes this issue. I'll backport it into ruby_2_1
anyway.
Updated by nagachika (Tomoyuki Chikanaga) about 10 years ago
- Status changed from Open to Closed
- % Done changed from 0 to 100
Applied in changeset ruby-21:r48177.
merge revision(s) r48174: [Backport #10438]
* configure.in: remove apple-gcc4.2 from CC candidates.
Updated by nagachika (Tomoyuki Chikanaga) about 10 years ago
- Status changed from Closed to Feedback
Updated by kimuraw (Wataru Kimura) about 10 years ago
I met same problem with clang compiler on OS X 10.7.
It looks configure script detects wrong RUBY_SETJMP() and RUBY_LONGJMP().
I found adding a configure option "--with-setjmp-type=_setjmp" solves this problem.
config.h on 10.9
#define RUBY_SETJMP(env) _setjmp((env))
#define RUBY_LONGJMP(env,val) _longjmp((env),val)
config.h on 10.7
#define RUBY_SETJMP(env) __builtin_setjmp((void **)(env))
#define RUBY_LONGJMP(env,val) __builtin_longjmp((void **)(env),val)
I collected build results of ruby-2.1.4 on some environments from my Mac and MacPorts' buildbot reports.
OS (uname -r) | compiler |miniruby
---------------+----------------------------------------------------------------------------+---------
10.10 (14.0.0) | Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) | ok
10.9 (13.4.0) | Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn) | ok
10.9 (13.2.0) | Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) | ok
10.8 (12.5.0) | Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) | ok
10.8 (12.5.0) | Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)| NG
10.7 (11.4.2) | Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn) | NG
10.6 (10.8.0) | gcc version 4.2.1 (Apple Inc. build 5666) (dot 3) | ok
Updated by nobu (Nobuyoshi Nakada) about 10 years ago
Thank you.
Possibly, it depends on the versions of based GCC?
Worked fine on 10.7 (11.4.2) with MacPorts gcc 4.7.3 or later,
but it's uncertain where is the borderline between 4.3 and 4.7.
Updated by nobu (Nobuyoshi Nakada) about 10 years ago
- Description updated (diff)
Updated by nobu (Nobuyoshi Nakada) about 10 years ago
- Is duplicate of Bug #10272: miniruby hangs on Mac OS X 10.7 added
Updated by nobu (Nobuyoshi Nakada) about 10 years ago
- Status changed from Feedback to Closed
Applied in changeset r48184.
configure.in: fix for old Apple compilers
- configure.in (__builtin_setjmp): disable with gcc/clang earlier
than 4.3 on Mac OS X. [ruby-core:65174] [Bug #10272]
Updated by pedz (Perry Smith) about 10 years ago
--gcc= and --cc= options to configure result in an error.
I did export CC=.... before the configure and that took effect but that did not solve my issue.
On my host, /usr/bin/gcc is the same as /usr/bin/gcc-4.2. /usr/bin/clang produced the same issue.
I will try --with-setjmp-type=_setjmp and report back
Updated by pedz (Perry Smith) about 10 years ago
Adding --with-setjmp-type=_setjmp to configure fixed my problem. I can compile, install, and make check passes as well.
Please let me know if I can help someway in debugging this issue.
Updated by nagachika (Tomoyuki Chikanaga) about 10 years ago
- Backport changed from 2.0.0: UNKNOWN, 2.1: REQUIRED to 2.0.0: DONTNEED, 2.1: DONE
r48184 was backported into ruby_2_1
at r48274.