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.  ¨Âìåáóáäöéóå éæ ôèéó éó ôèóáíå éóóõå¬ ïò éæ óåðáòáôå éóóõîååä> to be logged. Details below.
>
> While running tests in a rather simple Rails application, our development
> team has been seeing errors similar to:
> * ¨Âôôð󺯯çéôèõâ®ãïí¯ìóåçáì¯ùáòä¯éóóõåó¯´¹´
> * ¨Âôôð󺯯çéôèõâ®ãïí¯ìóåçáì¯ùáòä¯éóóõå󯳸²
>
> Which point to:
> http://bugs.ruby-lang.org/issues/4651
>
> We have observed this on both:
> * ¨ÂÈŶ®²¬ òõâù­±®¹®³­ð±²µ¬ Òáéì³®²®³®
> * ¨ÂÓØ ÌéïîÒõâù ±®¹®³­ð±²µÒáéì³®²®³¬ ØÃïä´®²®
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.  ¨Â ãá> 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.  ¨Âèéãè> where this might be either a slightly different cause or a slightly
> different manifestation of the same cause.  ¨Âùïãáóå÷å áòõóéîçöí®
>  ¨Âï÷åöåò äïî§ôèéîôèáô èááîùôèéîç ôï äï ÷éôè ôèéó éóóõ¨áîïôåéî
> the conversation on Issue 4651).

#4651 is clang+continuation issue, not GC.

> From the bug report: ¨Âôô𺯯âõçó®òõâù­ìáîç®ïòç¯éóóõåó¯´¶µ±
>
> 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 ¨Âõéìä òõâù­ôòõîë ÷éôè
> -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               ¨Âôôð󺯯çéôèõâ®ãïí¯òõâù¯òõâù¯âìïâ¯ö±ß¹ß³ß±²µ¯áòòáù®> (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) ¨Âåãïîãèáîçå éó íéóóéîòåìáôéîç ôï
> size_t and for loop. Line 695
> vm_inshelper.c ¨Âôôð󺯯çéôèõâ®ãïí¯òõâù¯òõâù¯âìïâ¯ö±ß¹ß³ß±²µ¯öíßéîóîèåìðåò®ããèáîçåó
> 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>