[ruby-core:44378] Re: Possible merge error of code in Issue 4651 on to Ruby 1.9.3-p125?

2012/4/16 Blythe,Aaron <[e-mail]>:
> tl;dr I believe I have uncovered a merge error to ruby 1.9.3-p125 from Issue
> 4651. lease 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:
> *ttps://github.com/lsegal/yard/issues/494
> *ttps://github.com/lsegal/yard/issues/382
>
> Which point to:
> http://bugs.ruby-lang.org/issues/4651
>
> We have observed this on both:
> *HEL 6.2, ruby-1.9.3-p125, Rails 3.2.3.
> *SX 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.  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. hich is
> where this might be either a slightly different cause or a slightly
> different manifestation of the same cause. s you can see we are using rvm.
> owever 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:ttp://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 canuild 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.cttps://github.com/ruby/ruby/blob/v1_9_3_125/array.c
> (changes are there, line numbers exactly the same)
> cont.chttps://github.com/ruby/ruby/blob/v1_9_3_125/cont.c
> (first change is there, line 452)econd change is missing relating to
> size_t and for loop. Line 695
> vm_inshelper.cttps://github.com/ruby/ruby/blob/v1_9_3_125/vm_insnhelper.cchanges
> 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 [e-mail]>