Bug #10438: miniruby hangs on Mac 10.8.5 during build of ruby 2.1.4

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.1.4p265 (2014-10-27 revision 48166) [x86_64-darwin12.0]
• Backport: 2.0.0: DONTNEED, 2.1: DONE

[pedz (Perry Smith)]

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.

[nagachika (Tomoyuki Chikanaga)]

• 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.

[nagachika (Tomoyuki Chikanaga)]

• 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.

[nagachika (Tomoyuki Chikanaga)]

• Status changed from Closed to Feedback

[kimuraw (Wataru Kimura)]

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

[nobu (Nobuyoshi Nakada)]

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.

[nobu (Nobuyoshi Nakada)]

• Description updated (diff)

[nobu (Nobuyoshi Nakada)]

• Is duplicate of Bug #10272: miniruby hangs on Mac OS X 10.7 added

[nobu (Nobuyoshi Nakada)]

• 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]

[pedz (Perry Smith)]

--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

[pedz (Perry Smith)]

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.

[nagachika (Tomoyuki Chikanaga)]

• 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.