Issue #10438 has been updated by 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.

----------------------------------------
Bug #10438: miniruby hangs on Mac 10.8.5 during build of ruby 2.1.4
https://bugs.ruby-lang.org/issues/10438#change-49690

* Author: Perry Smith
* Status: Feedback
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* ruby -v: ruby 2.1.4p265 (2014-10-27 revision 48166) [x86_64-darwin12.0]
* Backport: 2.0.0: UNKNOWN, 2.1: REQUIRED
----------------------------------------
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.




-- 
https://bugs.ruby-lang.org/