Project

General

Profile

Bug #10438

miniruby hangs on Mac 10.8.5 during build of ruby 2.1.4

Added by pedz (Perry Smith) almost 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 2.1.4p265 (2014-10-27 revision 48166) [x86_64-darwin12.0]
[ruby-core:65930]

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.

Related issues

Is duplicate of Ruby master - Bug #10272: miniruby hangs on Mac OS X 10.7Closed09/20/2014Actions

Associated revisions

Revision f14cc4d3
Added by nagachika (Tomoyuki Chikanaga) almost 5 years ago

merge revision(s) r48174: [Backport #10438]

    * configure.in: remove apple-gcc4.2 from CC candidates.

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_1@48177 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Revision 48177
Added by nagachika (Tomoyuki Chikanaga) almost 5 years ago

merge revision(s) r48174: [Backport #10438]

* configure.in: remove apple-gcc4.2 from CC candidates.

Revision fb3ed90d
Added by nagachika (Tomoyuki Chikanaga) almost 5 years ago

merge revision(s) r48184: [Backport #10272] [Backport #10438]

    * configure.in (__builtin_setjmp): disable with gcc/clang earlier
      than 4.3 on Mac OS X.  [ruby-core:65174] [Bug #10272]

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/branches/ruby_2_1@48274 b2dd03c8-39d4-4d8f-98ff-823fe69b080e

Revision 48274
Added by nagachika (Tomoyuki Chikanaga) almost 5 years ago

merge revision(s) r48184: [Backport #10272] [Backport #10438]

* configure.in (__builtin_setjmp): disable with gcc/clang earlier
  than 4.3 on Mac OS X.  [ruby-core:65174] [Bug #10272]

History

Updated by nagachika (Tomoyuki Chikanaga) almost 5 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) almost 5 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) almost 5 years ago

  • Status changed from Closed to Feedback

Updated by kimuraw (Wataru Kimura) almost 5 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) almost 5 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) almost 5 years ago

  • Description updated (diff)

Updated by nobu (Nobuyoshi Nakada) almost 5 years ago

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

Updated by nobu (Nobuyoshi Nakada) almost 5 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) almost 5 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) almost 5 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) almost 5 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.

Also available in: Atom PDF