From: "Blythe,Aaron" Date: 2012-04-16T11:53:29+09:00 Subject: [ruby-core:44372] Possible merge error of code in Issue 4651 on to Ruby 1.9.3-p125? --_000_CBB0F3D457308ablythecernercom_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" tl;dr I believe I have uncovered a merge error to ruby 1.9.3-p125 from Issu= e 4651. Please advise if this is the same issue, or if a separate issue ne= eds to be logged. Details below. While running tests in a rather simple Rails application, our development t= eam 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 provi= de the entire output, however I think the interesting part is the C level b= acktrace 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+0x= b8) [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_mar= k+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 differe= nt manifestation of the same cause. As you can see we are using rvm. Howe= ver 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/be953b4d1ce3f0d= fc7f24c84ec7a51e027102557 * 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/arr= ay.c (changes are there, line numbers exactly the same) * cont.c https://github.com/ruby/ruby/blob/v1_9_3_125/con= t.c (first change is there, line 452) Second change is miss= ing relating to size_t and for loop. Line 695 * vm_inshelper.c https://github.com/ruby/ruby/blob/v1_9_3_125/vm_insnhel= per.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 C= erner 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 in= formation is strictly prohibited and may be unlawful. If you are not the ad= dressee, please promptly delete this message and notify the sender of the d= elivery error by e-mail or you may call Cerner's corporate offices in Kansa= s City, Missouri, U.S.A at (+1) (816)221-1024. --_000_CBB0F3D457308ablythecernercom_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="ISO-8859-1"
= tl;dr I believe I have uncovered a merge error to ruby 1.9.3-p125 f= rom Issue 4651.  Please advise if this is the same issue, or if a sepa= rate issue needs to be logged. Details below.



While running tests in a rather simple Rails applicati= on, our development team has been seeing errors similar to:
*&nbs= p;h= ttps://github.com/lsegal/yard/issues/494
* https://github.c= om/lsegal/yard/issues/382

Which point to:
http://bugs.ruby-lang.org/issues/4651
=

We have observed this on= both:
* R= HEL 6.2, ruby-1.9.3-p125, Rails 3.2.3.
* OSX Lion, Ruby 1.9.3-p125, Rails 3.2.3, XCod= e 4.2.1

The detailed repo= rt is similar to the Yard issues noted above.  I can provide the entir= e output, however I think the interesting part is the C level backtrace pro= vided here:

 = ; &nbs= p; -- 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/rubie= s/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/libpthr= ead.so.0() [0x31de60f4a0]
    /home/semantic/.rvm/rubies/ruby-1.9.3-p125/lib/l= ibruby.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
 = ;  &n= bsp;/home/semantic/.rvm/rubies/ruby-1.9.3-p125/lib/libruby.so.1.9(+0= x76b7c) [0x7f8dc1ac9b7c] gc.c:1861
    /home/semantic/.rvm/rubies/ruby-1.9.3-p= 125/lib/libruby.so.1.9(+0x16366c) [0x7f8dc1bb666c] vm.c:1719

Which seems to point to the Garbage col= lector marking operation.  Which is where this might be either a sligh= tly 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 h= as anything to do with this issue (as noted in the conversation on Issue 46= 51).

=
From the bug report:=  h= ttp://bugs.ruby-lang.org/issues/4651

Github commit:      &= nbsp;   https://github.com/r= uby/ruby/commit/be953b4d1ce3f0dfc7f24c84ec7a51e027102557

* cont.c (cont_capt= ure): add volatile. 
On clang -O, it is needed to avoid the = optimization.
With this and llvm/clang's recent fix, clang 3.0 ca= n build ruby-trunk with -O option. 
* cont.c (cont_capt= ure): 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<= /a>

 

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 i= ssue needs to be logged.
CONFIDENTIALITY NOTICE This message and any included attachments are fr= om Cerner Corporation and are intended only for the addressee. The informat= ion contained in this message is confidential and may constitute inside or = non-public information under international, federal, or state securities la= ws. Unauthorized forwarding, printing, copying, distribution, or use of suc= h information is strictly prohibited and may be unlawful. If you are not th= e addressee, please promptly delete this message and notify the sender of t= he delivery error by e-mail or you may call Cerner's corporate offices = in Kansas City, Missouri, U.S.A at (+1) (816)221-1024.
--_000_CBB0F3D457308ablythecernercom_--