2012/4/16 Blythe,Aaron <ABLYTHE / cerner.com>:
> tl;dr I believe I have uncovered a merge error to ruby 1.9.3-p125 from Is=
sue
> 4651. =A0Please advise if this is the same issue, or if a separate issue =
needs
> to be logged. Details below.
>
> While running tests in a rather simple Rails application, our development
> team has been seeing errors similar to:
> *=A0https://github.com/lsegal/yard/issues/494
> *=A0https://github.com/lsegal/yard/issues/382
>
> Which point to:
> http://bugs.ruby-lang.org/issues/4651
>
> We have observed this on both:
> *=A0RHEL 6.2, ruby-1.9.3-p125, Rails 3.2.3.
> *=A0OSX Lion, Ruby 1.9.3-p125, Rails 3.2.3, XCode 4.2.1

Those report is not complete because a clean ruby environment don't have ya=
rd.

> The detailed report is similar to the Yard issues noted above. =A0I can
> provide the entire output, however I think the interesting part is the C
> level backtrace provided here:
>
> =A0=A0=A0=A0-- C level backtrace information
> -------------------------------------------
>
> =A0=A0=A0=A0/home/semantic/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9=
(+0x17a977)
> [0x7f8dc1bcd977] vm_dump.c:796
> =A0=A0=A0=A0/home/semantic/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9=
(+0x5e824)
> [0x7f8dc1ab1824] error.c:258
> =A0=A0=A0=A0/home/semantic/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9=
(rb_bug+0xb8)
> [0x7f8dc1ab19c8] error.c:277
> =A0=A0=A0=A0/home/semantic/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9=
(+0x10afd5)
> [0x7f8dc1b5dfd5] signal.c:609
> =A0=A0=A0=A0/lib64/libpthread.so.0() [0x31de60f4a0]
> =A0=A0=A0=A0/home/semantic/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9=
(rb_gc_mark+0x39)
> [0x7f8dc1aca7e9] gc.c:1635
> =A0=A0=A0=A0/home/semantic/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9=
(+0x163615)
> [0x7f8dc1bb6615] vm.c:251
> =A0=A0=A0=A0/home/semantic/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9=
(+0x76b7c)
> [0x7f8dc1ac9b7c] gc.c:1861
> =A0=A0=A0=A0/home/semantic/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9=
(+0x16366c)
> [0x7f8dc1bb666c] vm.c:1719
>
> Which seems to point to the Garbage collector marking operation. =A0Which=
 is
> where this might be either a slightly different cause or a slightly
> different manifestation of the same cause. =A0As you can see we are using=
 rvm.
> =A0However I don't think that has anything to do with this issue (as note=
d in
> the conversation on Issue 4651).

#4651 is clang+continuation issue, not GC.

> From the bug report:=A0http://bugs.ruby-lang.org/issues/4651
>
> Github
> commit:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0https://github.com/ruby/ruby/commit/=
be953b4d1ce3f0dfc7f24c84ec7a51e027102557
>
> * cont.c (cont_capture): add volatile.
> On clang -O, it is needed to avoid the optimization.
> With this and llvm/clang's recent fix, clang 3.0 can=A0build ruby-trunk w=
ith
> -O option.
> * cont.c (cont_capture): use for-loop.
> * array.c (rb_ary_each): add volatile and use it.
> * vm_insnhelper.c (vm_call_cfunc): ditto.
>
> Ruby 1.9.3-p125:=A0=A0=A0=A0=A0=A0https://github.com/ruby/ruby/tree/v1_9_=
3_125
>
> array.c=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0https://github.com/ru=
by/ruby/blob/v1_9_3_125/array.c
> (changes are there, line numbers exactly the same)
> cont.c=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0https://github.com/=
ruby/ruby/blob/v1_9_3_125/cont.c
> (first change is there, line 452)=A0Second change is missing relating to
> size_t and for loop. Line 695
> vm_inshelper.c=A0https://github.com/ruby/ruby/blob/v1_9_3_125/vm_insnhelp=
er.c=A0(changes
> are there, line numbers exactly the same)
>
>
>
> The odd part is the for loop seemed to be one of the central points of th=
is
> issue.
>
> Please advise if this is the same issue, or if a separate issue needs to =
be
> logged.

The for-loop hack is only a workaround.
I later found the root of the problem and fixed it in r34278.
So the ugly hack is not needed.

Anyway it seems an another problem from such GC related issue.

--=20
NARUSE, Yui =A0<naruse / airemix.jp>