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

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

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).

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.

----------------------------------------------------------------------
CONFIDENTIALITY NOTICE This message and any included attachments are from Cerner Corporation and are intended only for the addressee. The information contained in this message is confidential and may constitute inside or non-public information under international, federal, or state securities laws. Unauthorized forwarding, printing, copying, distribution, or use of such information is strictly prohibited and may be unlawful. If you are not the addressee, please promptly delete this message and notify the sender of the delivery error by e-mail or you may call Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1) [phone].