[#27919] 1.8.4 Preview2 検証 — "URABE Shyouhei aka. mput" <root@...>
卜部です。
まつもと ゆきひろです
[#27944] Ruby 1.8.3 on FreeBSD — Masayoshi Takahashi <maki@...>
高橋征義です。
[#27991] GC.always — Tanaka Akira <akr@...17n.org>
というように、GC を常に動かすというのは GC 関連の問題を発見
まつもと ゆきひろです
In article <1134314081.457781.8573.nullmailer@x31.priv.netlab.jp>,
[#27997] 1.8.4 documents? — "URABE Shyouhei aka. mput" <root@...>
卜部です。
新井です。
新井です。
[#28010] IA64 BSPSTORE — Tanaka Akira <akr@...17n.org>
そういえば、IA64 で gc.c や eval.c に BSPSTORE レジスタの値
まつもと ゆきひろです
In article <1134478762.181062.2779.nullmailer@x31.priv.netlab.jp>,
[#28045] 1.8.4 what remains? — "URABE Shyouhei aka. mput" <root@...>
卜部です。
[#28082] ruby_1_8 Segmentation fault on Cygwin — yanagi@...
柳田です。
山本です。
こんにちは、なかむら(う)です。
山本です。
こんにちは、なかむら(う)です。
柳田です。
山本です。
[#28087] test(?-, file1, file2) — Tanaka Akira <akr@...17n.org>
マニュアルの test(?-, file1, file2) の説明に、
[#28109] Kernel#fail — "URABE Shyouhei aka. mput" <root@...>
さすがにもう誰も使ってないのではないかと思います。Kernel#failは廃止にし
[#28121] post_connection_check with javacc.dev.java.net — Tanaka Akira <akr@...17n.org>
ふと、https://javacc.dev.java.net/ を open-uri でアクセスすると、
[#28127] Intel C++ Compiler and HP aC++/ANSI C on IA64 — Tanaka Akira <akr@...17n.org>
TestDrive で IA64 上の Intel C++ Compiler and HP aC++/ANSI C
渡辺哲也です。
[#28140] ia64-hpux11.23/socket.sl: this executable file can't load extension libraries (LoadError) — Tanaka Akira <akr@...17n.org>
HP-UX で HP aC++/ANSI C を使って作った ruby で、openssl や drb のテストをすると、
渡辺哲也です。
In article <200512280307.jBS37nnj005909@pbsg500.nifty.com>,
In message "[ruby-dev:28142] Re: ia64-hpux11.23/socket.sl: this executable file can't load extension libraries (LoadError)"
山本です。
In article <20051228210640.13C71A10.ocean@m2.ccsnet.ne.jp>,
渡辺哲也です。
山本です。
山本です。
In article <20051229114438.44D19F00.ocean@m2.ccsnet.ne.jp>,
なかだです。
In article <ypvtr77wv7q9.wl%nobuyoshi.nakada@ge.com>,
なかだです。
In article <ypvtoe30v1zk.wl%nobuyoshi.nakada@ge.com>,
なかだです。
In article <ypvtmzikv11x.wl%nobuyoshi.nakada@ge.com>,
なかだです。
In article <ypvtwthol15x.wl%nobuyoshi.nakada@ge.com>,
[#28177] Generator dumps core — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
[#28178] accessing ruby_cbase (nil) dumps core — SASADA Koichi <ko1@...>
ささだです。
[#28181] zsuper (with define_method) dumps core — SASADA Koichi <ko1@...>
ささだです。
[#28182] generator.rb deadlocks — Tanaka Akira <akr@...17n.org>
RUBY_ALWAYS_GC= つきで test_generator.rb を動かすと deadlock が起きます。
[#28184] test_each(TC_SyncEnumerator) fails. — Tanaka Akira <akr@...17n.org>
deadlock は解決しましたが次のようにテストが失敗します。
[ruby-dev:28046] Re: ruby 1.8 dumps core
山本です。
>rb_funcall では甘いんじゃないですかね。
>
>次のように ruby_xmalloc とかの garbage_collect 呼び出し条件
>を細工して常に GC させるようにすると、[ruby-dev:27905] のパッ
>チを当てても yaml っぽい感じで落ちます。
完治は無理でも、直せるところは直しておこうと HEAD でいじってみた結果、
私の環境では RUBY_ALWAYS_GC で SEGV することはなくなりました。しかしながら、
1) Error:
test_circular_references(YAML_Unit_Tests):
TypeError: can't convert Hash into String
E:/ruby-cvs/ruby/lib/yaml.rb:133:in `load'
E:/ruby-cvs/ruby/test/yaml/test_yaml.rb:1226:in `test_circular_references'
というエラーが毎回報告され、どうにも解消できません。(RUBY_ALWAYS_GC をつけずに
普通に testrb yaml すると報告されません)
デバッガを追った感じでは、メンバ変数が 0 フィルされたような妙な SyckNode が
syck_defaultresolver_node_import に渡ってきており、それが引き金になっている
ようにも見えましたがよくわかりません。(解放済みのノード?)
syck は rubyext.c 以外は python php などと共通で、ruby 固有の記述を持ち込めない
というのが非常にデバッグしにくいです。本来なら VALUE を持ちまわして、必要なとき
だけ生ポインタを取り出すのだと思いますが、それができません。
VALUE
syck_scalar_value_set( self, val )
VALUE self, val;
{
SyckNode *node;
Data_Get_Struct( self, SyckNode, node );
StringValue( val );
node->data.str->ptr = RSTRING(val)->ptr;
node->data.str->len = RSTRING(val)->len;
node->data.str->style = scalar_none;
rb_iv_set( self, "@value", val );
return val;
}
というように、RString の内部ポインタを取り出して保存するのがいかにも
怪しい感じでしたがこれも直接の原因ではなく、
syck_parser_assign_io で port がどこでも mark されなくなってしまうのが
原因かと思い、いじっていると返ってエラーが増えたり、
rb_syck_load_handler で
if (n->id > 0 && !NIL_P(obj))
{
MEMCPY((void *)n->id, (void *)obj, RVALUE, 1);
MEMZERO((void *)obj, RVALUE, 1);
obj = n->id;
}
なんて RValue をコピーしているのがいかにも怪しげでしたがここは実行されて
おらず・・・・
こんな状態ですが、1.8 へのバックポートについて検討していただければ幸いです。