[#28290] [Oniguruma] Version 4.0.0 — "K.Kosako" <sndgk393@...>
まつもとさん、
7 messages
2006/02/02
[#28296] packing small Struct — Tanaka Akira <akr@...17n.org>
しばらく前に思い付いたのですが、メモリ消費を押さえるために、
5 messages
2006/02/04
[#28337] constant look up order in CVS HEAD — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
15 messages
2006/02/18
[#28338] Re: constant look up order in CVS HEAD
— Tanaka Akira <akr@...17n.org>
2006/02/19
In article <1140229116.805371.31930.nullmailer@x31.priv.netlab.jp>,
[#28341] Re: constant look up order in CVS HEAD
— GOTOU Yuuzou <gotoyuzo@...>
2006/02/19
In message <87lkw8xfay.fsf@m17n.org>,
[#28342] Re: constant look up order in CVS HEAD
— Yukihiro Matsumoto <matz@...>
2006/02/19
まつもと ゆきひろです
[#28347] Re: constant look up order in CVS HEAD
— Tanaka Akira <akr@...17n.org>
2006/02/20
In article <1140392909.403432.7587.nullmailer@x31.priv.netlab.jp>,
[#28348] Re: constant look up order in CVS HEAD
— Yukihiro Matsumoto <matz@...>
2006/02/20
まつもと ゆきひろです
[#28352] Re: constant look up order in CVS HEAD
— WATANABE Hirofumi <eban@...>
2006/02/20
わたなべです。
[#28360] ruby_1_8 broken? — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
7 messages
2006/02/21
[#28371] bcc32 make error on 1.9.0 — "Nebata" <tnebata@...>
ねばたです。
8 messages
2006/02/22
[#28372] Re: bcc32 make error on 1.9.0
— KIMURA Koichi <kimura.koichi@...>
2006/02/22
木村です。
[#28386] test/drb/drbtest.rb cause file missing error — arton <artonx@...>
artonです。
6 messages
2006/02/23
[#28389] Re: test/drb/drbtest.rb cause file missing error
— Yukihiro Matsumoto <matz@...>
2006/02/24
まつもと ゆきひろです
[#28396] ruby-1.8 cvs head and 64bit time_t — arton <artonx@...>
artonです。
7 messages
2006/02/26
[#28404] irb cannot parse /\^/ — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
8 messages
2006/02/27
[#28405] Re: irb cannot parse /\^/
— keiju@... (石塚圭樹)
2006/02/27
けいじゅ＠いしつかです.
[ruby-dev:28304] Re: SEGV with zlib
From:
Yukihiro Matsumoto <matz@...>
Date:
2006-02-06 08:39:05 UTC
List:
ruby-dev #28304
まつもと ゆきひろです
In message "Re: [ruby-dev:28303] Re: SEGV with zlib"
on Mon, 6 Feb 2006 16:03:10 +0900, H.Yamamoto <ocean@m2.ccsnet.ne.jp> writes:
|確保した順番に関係なく、オブジェクトIDの小さいほうから free 関数を
|呼んでいるように見えます。つまり
|
| A(0x03) -> B(0x02) -> C(0x04)
|
|のように参照されていると、B が解放されて A の free 関数が解放済みの B
|にアクセスしてしまうと。
そういうことです。で、それは仕様だと思ってます。
|zlib.c では gzfile_writer_end で一応 OBJ_IS_FREED という形でチェックしている
|のですが、flags に出鱈目な値が入っているので、意図したように働いていません。
開放されてりゃzeroになってるはずなんですがね。デタラメな値が
入っているってことは再利用されちゃってるのかな。
|でも、これって zlib.c のバグというより GC のバグのような・・・
これをバグ認定するとすると、これから解放するオブジェクトに対
して、再度マークスイープを実行して...、とかいうようなことを
する必要が出てくるわけなんですが、それだけのGCの速度低下を許
容できる人はいないように思います。私が思いつかないだけで高速
な実装が可能なのかもしれませんが。
# えーと、今思いついたのは、たとえばスイープの前にマークされ
# てないT_DATAでもmark関数を呼んでおく(つまり、T_DATAからマー
# クされていると解放が1GCサイクル遅くなる)という手はあります
# けど、あんまりやりたくないです。
ということで、私としてはzlib.cに「finalizeの中で解放されてい
るかもしれないオブジェクトには触らないほうがよい(メソッド呼
び出すとかもってのほか)」とアドバイスしたいところであります。
まつもと ゆきひろ /:|)