Forum: Ruby-dev [ruby-trunk - Bug #8711][Open] 最近NoMemoryErrorが多い

9361878d459f1709feec780518946ee5?d=identicon&s=25 naruse (Yui NARUSE) (Guest)
on 2013-07-31 09:07
(Received via mailing list)
Issue #8711 has been reported by naruse (Yui NARUSE).

----------------------------------------
Bug #8711: 最近NoMemoryErrorが多い
https://bugs.ruby-lang.org/issues/8711

Author: naruse (Yui NARUSE)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: ruby 2.1.0dev (2013-07-30 trunk 42247) [x86_64-freebsd9.1]
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


最近 rubyci で NoMemoryError を出して失敗することが多いので、それを追跡するスレ

= TestFiber#test_many_fibers
http://u64b.rubyci.org/~chkbuild/ruby-trunk/log/20...
http://rbci.lakewood.privs.net/ruby-trunk/log/2013...

= FiberError: can't alloc machine stack to fiber
http://u64.rubyci.org/~chkbuild/ruby-trunk/log/201...
9361878d459f1709feec780518946ee5?d=identicon&s=25 naruse (Yui NARUSE) (Guest)
on 2013-08-01 11:08
(Received via mailing list)
Issue #8711 has been updated by naruse (Yui NARUSE).


http://u64b.rubyci.org/~chkbuild/ruby-trunk/log/20...
/proc/meminfo みても特にメモリが足りなくなっているようには見えないので悩んでいたところ、
卜部さんに setrlimit と ASLR のコンボでアドレス空間が無くなっているのではないかとの示唆を受け、
LIMIT_AS を増やしてみたところ、64bit 環境では再現しなくなりました。

32bit はこれから Process::RLIM_INFINITY を指定します。
----------------------------------------
Bug #8711: 最近NoMemoryErrorが多い
https://bugs.ruby-lang.org/issues/8711#change-40793

Author: naruse (Yui NARUSE)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: ruby 2.1.0dev (2013-07-30 trunk 42247) [x86_64-freebsd9.1]
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


最近 rubyci で NoMemoryError を出して失敗することが多いので、それを追跡するスレ

= TestFiber#test_many_fibers
http://u64b.rubyci.org/~chkbuild/ruby-trunk/log/20...
http://rbci.lakewood.privs.net/ruby-trunk/log/2013...

= FiberError: can't alloc machine stack to fiber
http://u64.rubyci.org/~chkbuild/ruby-trunk/log/201...
9361878d459f1709feec780518946ee5?d=identicon&s=25 naruse (Yui NARUSE) (Guest)
on 2013-08-01 13:18
(Received via mailing list)
Issue #8711 has been updated by naruse (Yui NARUSE).


http://u32.rubyci.org/~chkbuild/ruby-trunk/log/201...
で 32bit でも安定したような気がします。

もうしばらく様子を見ます。

より多くのアドレス空間を必要とするようになった事自体は仕様って理解でいいんですよね>ささださん
----------------------------------------
Bug #8711: 最近NoMemoryErrorが多い
https://bugs.ruby-lang.org/issues/8711#change-40794

Author: naruse (Yui NARUSE)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: ruby 2.1.0dev (2013-07-30 trunk 42247) [x86_64-freebsd9.1]
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


最近 rubyci で NoMemoryError を出して失敗することが多いので、それを追跡するスレ

= TestFiber#test_many_fibers
http://u64b.rubyci.org/~chkbuild/ruby-trunk/log/20...
http://rbci.lakewood.privs.net/ruby-trunk/log/2013...

= FiberError: can't alloc machine stack to fiber
http://u64.rubyci.org/~chkbuild/ruby-trunk/log/201...
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2013-08-19 07:38
(Received via mailing list)
(2013/08/01 20:18), naruse (Yui NARUSE) wrote:
> http://u32.rubyci.org/~chkbuild/ruby-trunk/log/201...
> で 32bit でも安定したような気がします。
>
> もうしばらく様子を見ます。
>
> より多くのアドレス空間を必要とするようになった事自体は仕様って理解でいいんですよね>ささださん

こちら、だいたいわかったんじゃないかなぁ、と思うので調査結果を報告します
(日本語)。小崎さん、チェックしてくれると助かります。

簡単な報告:
TestFiber#test_many_fibers が沢山仮想メモリを確保し、それを(なぜか)解
放しないため、その後の fork が ENOMEM で失敗します。

詳細な報告:

前提:
64bit OS で、2GB の物理メモリ+500MB の swap を持つシステム(VM)で検証
しています。Linux のバージョンは 3.2.0-51-generic。virtualbox 上で実行し
ています。

(1) TestFiber#test_many_fibers が仮想メモリを沢山確保してしまう

今は、Fiber のスタックは mmap で確保しています。Fiber が GC されると
munmap で解放するはずなんですが、何かの拍子にプロセスのアドレス空間が広
がったままになっているようです。これについては要検証。単に Fiber が GC
されない、というか、GC されたけど、実際の解放は遅延している、という気が
します。

Linux 側の RSS を見ると、1GB 弱しか使っていないことがわかりますが、仮想
メモリは 4GB ほど確保していることが観測できました。

Ruby 2.0 から、Fiber のためのスタックサイズが広がったため、この問題が生
じました(多分)。

(2) fork が ENOMEM で失敗

物理メモリ(+swap)以上の仮想メモリを持つプロセスを fork しようとする
と、ENOMEM が起って失敗するようです。

(3) ENOMEM になってしまう理由

Linux は、(デフォルトでは)一度に物理メモリ(+α)以上の mmap は出来な
いようになっているようです。

http://passingloop.tumblr.com/post/11957331420/ove...
> 0
>     オーバーコミット有効
>     一回の malloc で確保できるのは実際に利用可能なメモリの大きさまで

多分、この制限で fork() が失敗してるんじゃないかなぁ、と思います。ちなみ
に、このページの malloc って、mmap かなぁ。

Linux kernel のソースをおおざっぱに追ったのですが、fork() がこのチェック
をするところにどう到達するかは見ることが出来ませんでした。ので、推測にな
ります。


考えられる解決策:
- TestFiber#test_many_fibers を削除
- TestFiber#test_many_fibers を別プロセスで実行
- TestFiber#test_many_fibers 後にちゃんと物理メモリを解放するように頑張る


余談:
fork では、CoW になるから、ページテーブル操作だけ必要で、物理メモリの制
限はないだろー(fork 出来るだろう)、と思っていたんですが、そうでもない
んですね。

しかし、この Linux の制限って少し不思議ですね。mmap(4GB) を行うと、(3)
の条件で失敗しますが、mmap(2GB) を 2 回やると成功します。これだけだと連
続領域 4GB の確保が出来ないのかな、とも思いますが、実は MAP_WRITE を外す
と mmap(4GB) は成功します。どうやら、書き込み可能な部分だけ、この(3) の
チェックが入るようです。で、mprotect() で 2GB 単位でこの 4GB の連続領域
を書き込み可能にすることが可能です。つまり、

        size = 4GB;
  addr = mmap(0, size, PROT_EXEC | PROT_READ, ...);
  mprotect(addr       , size/2, 書き込み可能に);
  mprotect(addr+size/2, size/2, 書き込み可能に);

とすると、書き込み可能な 4GB の連続領域を得ることが出来ます。もちろん、
実際に書き込んでいくとページが割り当てられてメモリ足りなくなりますが。

こういう設計なのは、なにがしかの理由があるんでしょうけれども、意外でした。
02da662c083396641da96c1d32fc86ed?d=identicon&s=25 KOSAKI Motohiro (Guest)
on 2013-08-19 08:43
(Received via mailing list)
2013/8/19 SASADA Koichi <ko1@atdot.net>:
> (2013/08/01 20:18), naruse (Yui NARUSE) wrote:
>> http://u32.rubyci.org/~chkbuild/ruby-trunk/log/201...
>> $B$G(B 32bit $B$G$b0BDj$7$?$h$&$J5$$,$7$^$9!#(B
>>
>> $B$b$&$7$P$i$/MM;R$r8+$^$9!#(B
>>
>>
$B$h$jB?$/$N%"%I%l%96u4V$rI,MW$H$9$k$h$&$K$J$C$?;v<+BN$O;EMM$C$FM}2r$G$$$$$s$G$9$h$M!d$5$5$@$5$s(B
>
> $B$3$A$i!"$@$$$?$$$o$+$C$?$s$8$c$J$$$+$J$!!"$H;W$&$N$GD4::7k2L$rJs9p$7$^$9(B
> $B!JF|K\8l!K!#>.:j$5$s!"%A%'%C%/$7$F$/$l$k$H=u$+$j$^$9!#(B

$BD4::$*Hh$lMM$G$9!#(B
$B$3$A$i$G3NG'$7$?8B$j$G$O!"$3$NFbMF$G4V0c$$$J$$$H;W$o$l$^$9!#(B

> $B$F$$$^$9!#(B
> $B%a%b%j$O(B 4GB $B$[$I3NJ]$7$F$$$k$3$H$,4QB,$G$-$^$7$?!#(B
>
> Linux $B$O!"!J%G%U%)%k%H$G$O!K0lEY$KJ*M}%a%b%j!J!\&A!K0J>e$N(B mmap $B$O=PMh$J(B
> $B$$$h$&$K$J$C$F$$$k$h$&$G$9!#(B

$B$=$&$G$9$M!#(B

>
> http://passingloop.tumblr.com/post/11957331420/ove...
>> 0
>>     $B%*!<%P!<%3%_%C%HM-8z(B
>>     $B0l2s$N(B malloc $B$G3NJ]$G$-$k$N$O<B:]$KMxMQ2DG=$J%a%b%j$NBg$-$5$^$G(B
>
> $BB?J,!"$3$N@)8B$G(B fork() $B$,<:GT$7$F$k$s$8$c$J$$$+$J$!!"$H;W$$$^$9!#$A$J$_(B
> $B$K!"$3$N%Z!<%8$N(B malloc $B$C$F!"(Bmmap $B$+$J$!!#(B

$B$O$$!#$=$&$G$9(B


> Linux kernel $B$N%=!<%9$r$*$*$6$C$Q$KDI$C$?$N$G$9$,!"(Bfork() $B$,$3$N%A%'%C%/(B
> $B$r$9$k$H$3$m$K$I$&E~C#$9$k$+$O8+$k$3$H$,=PMh$^$;$s$G$7$?!#$N$G!"?dB,$K$J(B
> $B$j$^$9!#(B

$B$7$F$^$9!#(B

do_fork()
  copy_process()
    copy_mm()
      dup_mm()
        dup_mmap()
          security_vm_enough_memory_mm()
            __vm_enough_memory()

$B$H$$$&%k!<%H$K$J$j$^$9!#(B


> $B9M$($i$l$k2r7h:v!'(B
> - TestFiber#test_many_fibers $B$r:o=|(B
> - TestFiber#test_many_fibers $B$rJL%W%m%;%9$G<B9T(B
> - TestFiber#test_many_fibers $B8e$K$A$c$s$HJ*M}%a%b%j$r2rJ|$9$k$h$&$K4hD%$k(B

$B%7%9%F%`A4BN$G@)8B$,$+$+$C$F$$$k$N$GJL%W%m%;%9$G<B9T$OK\<AE*$G$O(B
$B$J$$$h$&$K;W$$$^$9!#(B
$B$A$c$s$H3+J|$9$k$h$&$K%F%9%H!J$H!"(BGC$B!K$rJQ$($F!"$=$b$=$b%7%9%F%`$N(B
$B%a%b%j$,>.$5$9$.$k$H$-$O%F%9%H$r%9%-%C%W$9$k$h$&$K$7$J$$$H!"(B
$BIT;W5D$J2U=j$G%(%i!<$rEG$/$H;W$$$^$9!#(B



> $B$r=q$-9~$_2DG=$K$9$k$3$H$,2DG=$G$9!#$D$^$j!"(B
>
>         size = 4GB;
>         addr = mmap(0, size, PROT_EXEC | PROT_READ, ...);
>         mprotect(addr       , size/2, $B=q$-9~$_2DG=$K(B);
>         mprotect(addr+size/2, size/2, $B=q$-9~$_2DG=$K(B);
>
> $B$H$9$k$H!"=q$-9~$_2DG=$J(B 4GB $B$NO"B3NN0h$rF@$k$3$H$,=PMh$^$9!#$b$A$m$s!"(B
> $B<B:]$K=q$-9~$s$G$$$/$H%Z!<%8$,3d$jEv$F$i$l$F%a%b%jB-$j$J$/$J$j$^$9$,!#(B

$BA4$/$=$NDL$j$G$9!#(B


> $B$3$&$$$&@_7W$J$N$O!"$J$K$,$7$+$NM}M3$,$"$k$s$G$7$g$&$1$l$I$b!"0U30$G$7$?!#(B

$B$$$d!"$3$l$ONr;KE*$J%4%_$J$N$G!"$"$s$^$j5$$K$7$J$/$F$$$$$G$9!#(B
overcommit_always
$B$,$-$A$C$H$7$?4IM}$G!"(Bovercommit_guess$B$O4pK\E*$K(B
$B%A%'%C%/$7$J$$$1$I!"$"$^$j$K$b%"%[$J%5%$%:$O$-$C$H%*%Z%_%9$@$+$i(B
$B=u$1$F$d$m$&!#$0$i$$$N%N%j(B

$B$A$c$s$H@_7W$5$l$F$J$$$N$G!"(Bmprotect$B$^$o$j$GL7=b$,H/@8$7$F$*$j!"(B
$B:G=i$K(B PROT_READ$B$G(Bmap$B$7$F$+$i!"(BPROT_WRITE$B$KJQ$($k$H(B
$B%"%+%&%s%H$5$l$J$$(B $B"*(B $B%"%+%&%s%H$5$l$k(B $B$HA+0\$9$k$1$I!"(B
$B5U$K(BPROT_WRITE$B$G(Bmap$B$7$F(BPROT_READ$B$KJQ99$9$k$H%"%+%&%s%H$5$l$k(B
$B$^$^$J$N$@$h!#0l2s(Bwrite mode$B$K$J$C$F$7$^$&$H2?$,=q$$$F$"$k$+(B
$BJ,$+$i$J$$$+$i$=$&$9$k$7$+$J$$$s$@$1$I!"1x$$!#(B
$B$=$7$F?t!9$N4*0c$$%"%W%j%3!<%I$r@8$s$@$N$G$"$C$?!#(B
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2013-08-19 10:57
(Received via mailing list)
(2013/08/19 15:42), KOSAKI Motohiro wrote:
>> > $B9M$($i$l$k2r7h:v!'(B
>> > - TestFiber#test_many_fibers $B$r:o=|(B
>> > - TestFiber#test_many_fibers $B$rJL%W%m%;%9$G<B9T(B
>> > - TestFiber#test_many_fibers $B8e$K$A$c$s$HJ*M}%a%b%j$r2rJ|$9$k$h$&$K4hD%$k(B
> $B%7%9%F%`A4BN$G@)8B$,$+$+$C$F$$$k$N$GJL%W%m%;%9$G<B9T$OK\<AE*$G$O(B
> $B$J$$$h$&$K;W$$$^$9!#(B
> $B$A$c$s$H3+J|$9$k$h$&$K%F%9%H!J$H!"(BGC$B!K$rJQ$($F!"$=$b$=$b%7%9%F%`$N(B
> $B%a%b%j$,>.$5$9$.$k$H$-$O%F%9%H$r%9%-%C%W$9$k$h$&$K$7$J$$$H!"(B
> $BIT;W5D$J2U=j$G%(%i!<$rEG$/$H;W$$$^$9!#(B

$B%W%m%;%9$,HnBg2=$7!"85$KLa$i$J$$$N$,860x$N$h$&$J$N$G!"$H$j$"$($:1~5^=hCV(B
$B$K$O$J$k$+$H!#(B

$B$G!"(Bfork() $B$,<:GT$9$k>r7o$O!"0lEY$K(B mmap
$B$G$-$J$$$h$&$JO"B3$7$?%a%b%jNN(B
$B0h$,$"$k>l9g$J$N$G$9$,!"2?$+$HD4$Y$?$j9M$($?$j$7$?$H$3$m!"!J$^$@3N>Z$O$J(B
$B$$$N$G$9$,!K(BVM $B$N%9%?%C%/$G$"$k$3$H$K;W$$;j$j$^$7$?!#(B

$B8=>u!"(BVM stack $B$O(B Fiber $B@8@.;~!"$*$h$S(B Fiber
$B2rJ|;~$K3d$jEv$F!"2rJ|$r(B
ALLOC_N()$B!"$D$^$j(B malloc()
$B7PM3$G9T$C$F$$$^$9!#$3$l$K$O$$$/$D$+LdBj$,$"(B
$B$j$^$9!#(B

(1) Fiber $B$N=i2s5/F0A0!"$*$h$S(B Fiber $B$N=*N;8e$K$O(B VM stack
$B$OITMW(B
(2) malloc $B$G3d$jEv$F$F$$$k$?$a!"(Bfree $B$7$F$b(B OS
$B$KJV$9$+$I$&$+$OITL@(B

(1)
$B$O!"C1=c$K2~NI$r$9$l$P$$$$$@$1$G$9!#$?$@$7!"JQ99$O$A$g$C$HLLE]$=$&$G$9!#(B

(2) $B$O!"Nc$($P(B mmap
$B$K$9$l$P2r7h$7$^$9$,!"%7%9%F%`%3!<%k$N%*!<%P%X%C%I$r(B
$B$I$&9M$($k$+!"$H$$$&$3$H$K$J$k$+$H;W$$$^$9!#M}A[E*$K$O!"(BFiber $B$,(B
burst
$BE*$KH/@8$9$k!"$H$$$&A0Ds$G$O!"=i4|CM$O>.$5$/!"%*!<%P!<%U%m!<$7$=$&$K$J$C(B
$B$?$iA}$d$7$F$$$/$h$&$J46$8$K$7$?$$$H;W$C$F5o$^$9!J$3$l$O%9%l%C%I$bF1(B
$B$8!K!#$,!"$3$l$O@($/LLE]$JOC!#(B

$B$H$j$"$($:!"Ev3:%F%9%H$G(B GC.start
$B$r$9$k!"$H$$$&9x:U$1$JBP1~$K$J$C$F$$$^$9!#(B
02da662c083396641da96c1d32fc86ed?d=identicon&s=25 KOSAKI Motohiro (Guest)
on 2013-08-19 17:34
(Received via mailing list)
2013/8/19 SASADA Koichi <ko1@atdot.net>:
>
>
>
> $B$H$j$"$($:!"Ev3:%F%9%H$G(B GC.start
$B$r$9$k!"$H$$$&9x:U$1$JBP1~$K$J$C$F$$$^$9!#(B

$B$(!<$H!"(BENOMEM$B$,=P$k$+$i$K$O(BGB$BC10L$N%a%b%j$,L$3+J|$G$J$$$H$$$1$J$$$N$G$9$,!"(B
$B$J$s$G(Bfree$B$7$F$b(BOS$B$KLa$C$F$J$$$s$G$7$g$&!#(B
$B<B32$,$"$k$N$,J,$+$C$F$$$k$N$@$+$i!"<j$rF~$l$?$[$&$,$h$$$N$G$O$J$$$+$H(B
308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 SASADA Koichi (Guest)
on 2013-08-20 00:03
(Received via mailing list)
(2013/08/20 0:33), KOSAKI Motohiro wrote:
>
$B$(!<$H!"(BENOMEM$B$,=P$k$+$i$K$O(BGB$BC10L$N%a%b%j$,L$3+J|$G$J$$$H$$$1$J$$$N$G$9$,!"(B
> $B$J$s$G(Bfree$B$7$F$b(BOS$B$KLa$C$F$J$$$s$G$7$g$&!#(B

malloc
$B$N%i%$%V%i%j$NLdBj$8$c$J$$$+$J$!!"$H!#4*$G$9!#$I$&$d$C$FD4$Y$k$N(B
$B$,$$$$$N$+$J!#(B

> $B<B32$,$"$k$N$,J,$+$C$F$$$k$N$@$+$i!"<j$rF~$l$?$[$&$,$h$$$N$G$O$J$$$+$H(B

$BC1$K!"3+H/M%@hEY$NLdBj$G$9$M!#(B(1)
$B$O=PMh$=$&$@$J!"$H;W$C$?$s$@$1$I!"$J$s(B
$B$+:.$_9g$C$F$$$F!"D>$9$N$O5$9g$$$rF~$l$kI,MW$,$"$j$=$&$J$N$G!"$^$@$d$C$F(B
$B$$$J$$$H$$$&OC$G$9!#(B
B11f10c4cd9d53970e7be20caa43f940?d=identicon&s=25 Tanaka Akira (Guest)
on 2013-08-20 06:23
(Received via mailing list)
2013$BG/(B8$B7n(B19$BF|(B 15:42 KOSAKI Motohiro
<kosaki.motohiro@gmail.com>:

>> $B9M$($i$l$k2r7h:v!'(B
>> - TestFiber#test_many_fibers $B$r:o=|(B
>> - TestFiber#test_many_fibers $B$rJL%W%m%;%9$G<B9T(B
>> - TestFiber#test_many_fibers $B8e$K$A$c$s$HJ*M}%a%b%j$r2rJ|$9$k$h$&$K4hD%$k(B
>
> $B%7%9%F%`A4BN$G@)8B$,$+$+$C$F$$$k$N$GJL%W%m%;%9$G<B9T$OK\<AE*$G$O(B
> $B$J$$$h$&$K;W$$$^$9!#(B
> $B$A$c$s$H3+J|$9$k$h$&$K%F%9%H!J$H!"(BGC$B!K$rJQ$($F!"$=$b$=$b%7%9%F%`$N(B
> $B%a%b%j$,>.$5$9$.$k$H$-$O%F%9%H$r%9%-%C%W$9$k$h$&$K$7$J$$$H!"(B
> $BIT;W5D$J2U=j$G%(%i!<$rEG$/$H;W$$$^$9!#(B

$BJL%W%m%;%9$G%F%9%H$r<B9T$9$l$P!"$=$N%F%9%H$,MW5a$7$?%a%b%j$O!"(B
$B$=$N%W%m%;%9$,=*N;$7$5$($9$l$P2rJ|$5$l$k!"$H$$$&OC$K;W$($k$N$G$9$,!"(B
$B$J$K$,LdBj$J$N$G$7$g$&$+!#(B

$B%W%m%;%9$,=*N;$7$F$b1F6A$,;D$k2DG=@-$rH]Dj$G$-$J$$$H$$$&OC$,$"$k$N$G$7$g$&$+!#(B
02da662c083396641da96c1d32fc86ed?d=identicon&s=25 KOSAKI Motohiro (Guest)
on 2013-08-20 08:06
(Received via mailing list)
2013/8/20 Tanaka Akira <akr@fsij.org>:
>> $B%a%b%j$,>.$5$9$.$k$H$-$O%F%9%H$r%9%-%C%W$9$k$h$&$K$7$J$$$H!"(B
>> $BIT;W5D$J2U=j$G%(%i!<$rEG$/$H;W$$$^$9!#(B
>
> $BJL%W%m%;%9$G%F%9%H$r<B9T$9$l$P!"$=$N%F%9%H$,MW5a$7$?%a%b%j$O!"(B
> $B$=$N%W%m%;%9$,=*N;$7$5$($9$l$P2rJ|$5$l$k!"$H$$$&OC$K;W$($k$N$G$9$,!"(B
> $B$J$K$,LdBj$J$N$G$7$g$&$+!#(B
>
>
$B%W%m%;%9$,=*N;$7$F$b1F6A$,;D$k2DG=@-$rH]Dj$G$-$J$$$H$$$&OC$,$"$k$N$G$7$g$&$+!#(B

$B%7%9%F%`A4BN$N%j%_%C%H$K0z$C$+$+$C$?>l9g!";`$L$N$O(Bruby$B$+$b$7$l$J$$$7!"(B
$B$^$C$?$/(Bruby$B$H4X78$J$$JL$N%W%m%;%9$+$b$7$l$J$$!#C/$,%P%P$r0z$/$+$O3NDjE*$K$O(B
$B$$$($J$$$N$G$O$J$$$G$7$g$&$+!#(B

$B%F%9%H7k2L$+$i$9?dB,$9$k$K!":#$N$5$5$@$5$s$N4D6-$G$O(Bruby$B0J30$KBgNL$N(B
$B%"%m%1!<%H$9$k%W%m%;%9$O$$$J$$$h$&$G$9$,!J$=$N$?$a!"(BRuby$B$@$1$,$7$-$$CM$rD6$($k2DG=@-$,$"$k!K(B
$B0lHLE*$K$OJ]>Z$N$J$$OC$@$H;W$$$^$9!#(B

$B$5$i$K$$$&$H!"(BFiber$B$r;H$&$H(BVM$B%9%?%C%/$,$H$s$G$b$J$/HnBg2=$9$k!J2DG=@-$,$"$k!K$H$$$&$N$O(B
$BJL$K%F%9%H4D6-0J30$G$bH/@8$7$&$k>r7o$G$9$h$M!#(B
02da662c083396641da96c1d32fc86ed?d=identicon&s=25 KOSAKI Motohiro (Guest)
on 2013-08-20 08:07
(Received via mailing list)
>>
$B$(!<$H!"(BENOMEM$B$,=P$k$+$i$K$O(BGB$BC10L$N%a%b%j$,L$3+J|$G$J$$$H$$$1$J$$$N$G$9$,!"(B
>> $B$J$s$G(Bfree$B$7$F$b(BOS$B$KLa$C$F$J$$$s$G$7$g$&!#(B
>
> malloc $B$N%i%$%V%i%j$NLdBj$8$c$J$$$+$J$!!"$H!#4*$G$9!#$I$&$d$C$FD4$Y$k$N(B
> $B$,$$$$$N$+$J!#(B

$B$^$:!"(BLD_PRELOAD$B$G0c$&(Bmalloc$B%m!<%I$7$F$b:F8=$9$k$+3NG'$9$k$H$3$m$+$i$8$c$J$$$G$7$g$&$+!#(B
Eabad423977cfc6873b8f5df62b848a6?d=identicon&s=25 hsbt (Hiroshi SHIBATA) (Guest)
on 2013-11-29 11:43
(Received via mailing list)
Issue #8711 has been updated by hsbt (Hiroshi SHIBATA).

Status changed from Open to Feedback

こちらどうでしょう。時間経っていますが引き続き調査します?
----------------------------------------
Bug #8711: 最近NoMemoryErrorが多い
https://bugs.ruby-lang.org/issues/8711#change-43255

Author: naruse (Yui NARUSE)
Status: Feedback
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: ruby 2.1.0dev (2013-07-30 trunk 42247) [x86_64-freebsd9.1]
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


最近 rubyci で NoMemoryError を出して失敗することが多いので、それを追跡するスレ

= TestFiber#test_many_fibers
http://u64b.rubyci.org/~chkbuild/ruby-trunk/log/20...
http://rbci.lakewood.privs.net/ruby-trunk/log/2013...

= FiberError: can't alloc machine stack to fiber
http://u64.rubyci.org/~chkbuild/ruby-trunk/log/201...
8cbb39dadafaf2287a83a13ee4981ec9?d=identicon&s=25 usa (Usaku NAKAMURA) (Guest)
on 2013-11-29 11:50
(Received via mailing list)
Issue #8711 has been updated by usa (Usaku NAKAMURA).

Status changed from Feedback to Closed

ちょっと正確なrevisionは出ませんが、最近の笹田さんと樽家さんの変更で
問題が出なくなったんじゃないかと。
一応閉じておきます。
----------------------------------------
Bug #8711: 最近NoMemoryErrorが多い
https://bugs.ruby-lang.org/issues/8711#change-43258

Author: naruse (Yui NARUSE)
Status: Closed
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: ruby 2.1.0dev (2013-07-30 trunk 42247) [x86_64-freebsd9.1]
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN


最近 rubyci で NoMemoryError を出して失敗することが多いので、それを追跡するスレ

= TestFiber#test_many_fibers
http://u64b.rubyci.org/~chkbuild/ruby-trunk/log/20...
http://rbci.lakewood.privs.net/ruby-trunk/log/2013...

= FiberError: can't alloc machine stack to fiber
http://u64.rubyci.org/~chkbuild/ruby-trunk/log/201...
This topic is locked and can not be replied to.