From: "NARUSE, Yui" <naruse@...>
Date: 2012-04-16T13:40:19+09:00
Subject: [ruby-core:44378] Re: Possible merge error of code in Issue 4651 on to Ruby 1.9.3-p125?

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 Issue
> 4651. �Please 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:
> *�https://github.com/lsegal/yard/issues/494
> *�https://github.com/lsegal/yard/issues/382
>
> Which point to:
> http://bugs.ruby-lang.org/issues/4651
>
> We have observed this on both:
> *�RHEL 6.2, ruby-1.9.3-p125, Rails 3.2.3.
> *�OSX 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 yard.

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

#4651 is clang+continuation issue, not GC.

> From the bug report:�http://bugs.ruby-lang.org/issues/4651
>
> Github
> commit:����������https://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�build ruby-trunk with
> -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:������https://github.com/ruby/ruby/tree/v1_9_3_125
>
> array.c���������������https://github.com/ruby/ruby/blob/v1_9_3_125/array.c
> (changes are there, line numbers exactly the same)
> cont.c����������������https://github.com/ruby/ruby/blob/v1_9_3_125/cont.c
> (first change is there, line 452)�Second change is missing relating to
> size_t and for loop. Line 695
> vm_inshelper.c�https://github.com/ruby/ruby/blob/v1_9_3_125/vm_insnhelper.c�(changes
> are there, line numbers exactly the same)
>
>
>
> The odd part is the for loop seemed to be one of the central points of this
> 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.

-- 
NARUSE, Yui �<naruse@airemix.jp>