[#25010] test_flush fails. — "URABE Shyouhei aka.mput" <root@...>
mput です。以下のように test_flush が失敗します。
[#25031] Method#to_proc とブロックの引渡し — Masahiro Sakai (酒井政裕) <sakai@...>
酒井といいます。
[#25035] 拡張ライブラリへの共有ライブラリのPATHの埋め込み — Takahiro Kambe <taca@...>
こんにちは。
なかだです。
In message <200412060607.iB667giF007533@sharui.nakada.niregi.kanuma.tochigi.jp>
なかだです。
In message <200412070015.iB70FAiF012770@sharui.nakada.niregi.kanuma.tochigi.jp>
2004-12-07 (火) の 12:27 +0900 に Takahiro Kambe さんは書きました:
こんにちは、なかむら(う)です。
In message <1102395885.21598.19.camel@rice.p.arika.org>
なかだです。
In message <200412071613.iB7GD2r4007918@sharui.nakada.niregi.kanuma.tochigi.jp>
[#25041] temporal locking already locked string on simultaneous write — Tanaka Akira <akr@...17n.org>
同じ文字列をほぼ同時に IO に書き込むと、temporal locking already
まつもと ゆきひろです
In article <1102133507.339625.10453.nullmailer@x31.priv.netlab.jp>,
In article <1102176395.383559.21204.nullmailer@x31.priv.netlab.jp>,
まつもと ゆきひろです
Tietew です。
[#25054] rexml — Takahiro Kambe <taca@...>
こんばんは。
なかだです。
In message <200412051451.iB5EpYiF009060@sharui.nakada.niregi.kanuma.tochigi.jp>
まつもと ゆきひろです
In message <1102290330.040938.1210.nullmailer@x31.priv.netlab.jp>
[#25096] double free problem — "Akinori MUSHA" <knu@...>
ご無沙汰しております。
Hi,
In article <1102401703.030252.2480.nullmailer@x31.priv.netlab.jp>,
まつもと ゆきひろです
Yukihiro Matsumoto wrote:
Yukihiro Matsumoto wrote:
In article <41BEF768.7030008@ttsky.net>,
Tanaka Akira wrote:
[#25101] non-stdio buffering — Tanaka Akira <akr@...17n.org>
えぇと、今回 1.9 でなにが起きたのかを私が把握している範囲でまとめてお
こんにちは、なかむら(う)です。
In article <20041208.033521.635728872.gotoyuzo@sawara.does.notwork.org>,
[#25103] ruby_xrealloc dumps core — Tietew <tietew-ml-ruby-dev@...>
Tietew です。
[#25134] Set/test_eq failed on Tru64UNIX — Minero Aoki <aamine@...>
青木です。
なかだです。
まつもと ゆきひろです
[#25152] 1.8 reopen problem with duplex popen — Tanaka Akira <akr@...17n.org>
次のように、1.8 で双方向 popen な IO を reopen するとエラーになること
なかだです。
In article <200412110142.iBB1gDIh004622@sharui.nakada.niregi.kanuma.tochigi.jp>,
なかだです。
わたなべです。
In article <41-Tue21Dec2004123451+0900-eban@os.rim.or.jp>,
[#25158] core dump on NetBSD 2.0 — Tanaka Akira <akr@...17n.org>
NetBSD 2.0 で次のようにすると core を吐きます。
In article <87hdmsivva.fsf@serein.a02.aist.go.jp>,
In article <87ekhwiv7g.fsf@serein.a02.aist.go.jp>,
なかだです。
In article <200412130040.iBD0e8Qh003275@sharui.nakada.niregi.kanuma.tochigi.jp>,
まつもと ゆきひろです
In article <1102906796.625997.23964.nullmailer@x31.priv.netlab.jp>,
前田です。
In article <41BD40DC.6030706@ruby-lang.org>,
まつもと ゆきひろです
[#25160] ripper in snapshot.tar.gz — Tanaka Akira <akr@...17n.org>
ふと、とある autoconf も bison も入っていない環境で Ruby をコンパイル
[#25193] 1.8.2 release schedule — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
[#25226] Zlib::Deflate.deflate dumps core — Tanaka Akira <akr@...17n.org>
次のようにすると core を吐きます。
[#25236] BSD/OS rlim_t — OHARA Shigeki <os@...>
大原です。
[#25252] core dump if local_append_gen invokes GC — Tanaka Akira <akr@...17n.org>
先程 1.9 を make test-all したところ、
[#25270] BSD/OS LDSHARED — OHARA Shigeki <os@...>
大原です。
[#25283] 1.8.2 preview4 — Yukihiro Matsumoto <matz@...>
Hello,
[#25292] tkutil is installed on no tcl/tk environment — Tanaka Akira <akr@...17n.org>
ふと気がついたのですが、Tcl/Tk が入っていない環境でも、tkutil は
[#25299] Re: リリース準備 — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
高橋征義です。
山本です。
小西 弘将です。
山本です。
山本です。
山本です。
永井@知能.九工大です.
[#25302] test_readline.rb blocks on BSD again — GOTOU Yuuzou <gotoyuzo@...>
In message <20041223175402.3116FC6718@lithium.ruby-lang.org>,
In message <20041224.131211.846943951.gotoyuzo@sawara.does.notwork.org>,
まつもと ゆきひろです
わたなべです。
In message <20041225140050.378109.eban@os.rim.or.jp>,
なかだです。
In article <200412251620.iBPGK1xA009288@sharui.nakada.niregi.kanuma.tochigi.jp>,
なかだです。
In article <200412260300.iBQ3038u005055@sharui.nakada.niregi.kanuma.tochigi.jp>,
[#25336] webrick/httpauth.rb must require 'base64' — sheepman <sheepman@...>
こんにちは、sheepman です。
[#25341] String#center dumps core — Tanaka Akira <akr@...17n.org>
次のようにすると core を吐きます。
なかだです。
[#25342] 1.9.0でbcc版がコンパイルできない — 小西 弘将 <konishih@...6.so-net.ne.jp>
小西 弘将です。
山本です。
[#25365] method(:p).to_proc.call([]) — Masahiro Sakai (酒井政裕) <sakai@...>
酒井です。
[#25370] FileUtils.copy_stream on nonblocking IO — Tanaka Akira <akr@...17n.org>
FileUtils.copy_stream を nonblocking な IO に対して使うと、次のように
[ruby-dev:25189] ruby_eval_tree
[ruby-dev:25159] の話のつづきですが、ruby_eval_tree っていまはどういう
扱いなんでしょうか?
Index: array.c
===================================================================
RCS file: /src/ruby/array.c,v
retrieving revision 1.170
diff -u -p -r1.170 array.c
--- array.c 18 Nov 2004 03:45:23 -0000 1.170
+++ array.c 13 Dec 2004 16:23:31 -0000
@@ -242,6 +242,7 @@ ary_make_shared(ary)
VALUE ary;
{
if (!FL_TEST(ary, ELTS_SHARED)) {
+ rb_gc();
NEWOBJ(shared, struct RArray);
OBJSETUP(shared, rb_cArray, T_ARRAY);
という変更を加えて make すると
% make
gcc -g -O2 -I. -I. -c array.c
ar rcu libruby-static.a array.o ascii.o bignum.o class.o compar.o dir.o dln.o enum.o error.o euc_jp.o eval.o file.o gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o random.o range.o re.o regcomp.o regenc.o regerror.o regexec.o reggnu.o regparse.o ruby.o signal.o sjis.o sprintf.o st.o string.o struct.o time.o utf8.o util.o variable.o version.o dmyext.o
gcc main.o libruby-static.a -ldl -lcrypt -lm -o miniruby -g -O2 -rdynamic
: [BUG] unknown node type 0
ruby 1.9.0 (2004-12-13) [i686-linux]
という問題が発生するのですが、次のようにして調べるとどうやらこれは
ruby_eval_tree が GC されてしまったことが原因のように思えます。
| % make -n
| ./miniruby ./mkconfig.rb -timestamp=.rbconfig.time \
| -install_name=ruby \
| -so_name=ruby rbconfig.rb
| ./miniruby ./ext/extmk.rb --dest-dir="" --make="make" --mflags="-n" --make-flags="n" --extout=".ext" --extension --extstatic --
| % gdb miniruby
| GNU gdb 6.1-debian
| Copyright 2004 Free Software Foundation, Inc.
| GDB is free software, covered by the GNU General Public License, and you are
| welcome to change it and/or distribute copies of it under certain conditions.
| Type "show copying" to see the conditions.
| There is absolutely no warranty for GDB. Type "show warranty" for details.
| This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/libthread_db.so.1".
|
GC に break point を設定
| (gdb) break garbage_collect
| Breakpoint 1 at 0x8071a13: file gc.c, line 1295.
とりあえず実行してみる
| (gdb) run ./mkconfig.rb -timestamp=.rbconfig.time -install_name=ruby -so_name=ruby rbconfig.rb
| Starting program: /home/akr/ruby/head-ruby/ruby/miniruby ./mkconfig.rb -timestamp=.rbconfig.time -install_name=ruby -so_name=ruby rbconfig.rb
|
| Breakpoint 1, garbage_collect () at gc.c:1295
| 1295 SET_STACK_END;
GC が起動している
| (gdb) c
| Continuing.
| : [BUG] unknown node type 0
| ruby 1.9.0 (2004-12-13) [i686-linux]
|
|
| Program received signal SIGABRT, Aborted.
| 0x4009e6b1 in kill () from /lib/libc.so.6
落ちているが、起動から終了までに GC は一回しか起きていない
| (gdb) up
| #1 0x4009e435 in raise () from /lib/libc.so.6
| (gdb)
| #2 0x4009f978 in abort () from /lib/libc.so.6
| (gdb)
| #3 0x080d58d6 in rb_bug (fmt=0x0) at error.c:214
| 214 abort();
| (gdb)
| #4 0x0805b4bd in rb_eval (self=1075673536, n=0x0) at eval.c:3868
| 3868 rb_bug("unknown node type %d", nd_type(node));
| (gdb) p node
| $1 = (NODE * volatile) 0x401c7b4c
| (gdb) p *(NODE * volatile) 0x401c7b4c
| $2 = {flags = 0, nd_file = 0x401c7b38 "", u1 = {node = 0x401c7bc4,
| id = 1075608516, value = 1075608516, cfunc = 0x401c7bc4,
| tbl = 0x401c7bc4}, u2 = {node = 0x401c3dbc, id = 1075592636,
| argc = 1075592636, value = 1075592636}, u3 = {node = 0x401c7b38,
| id = 1075608376, state = 1075608376, entry = 0x401c7b38, cnt = 1075608376,
| value = 1075608376}}
問題の NODE は flags が 0 なので GC されていることが確認される。
| (gdb) up
| #5 0x08055dfd in ruby_exec_internal () at eval.c:1470
| 1470 eval_node(ruby_top_self, ruby_eval_tree);
| (gdb) p ruby_eval_tree
| $3 = (NODE *) 0x401c7b4c
ここで ruby_eval_tree から GC された NODE が参照されていたことがわかる
もう一回実行する
| (gdb) run ./mkconfig.rb -timestamp=.rbconfig.time -install_name=ruby -so_name=ruby rbconfig.rb
| The program being debugged has been started already.
| Start it from the beginning? (y or n) y
|
| Starting program: /home/akr/ruby/head-ruby/ruby/miniruby ./mkconfig.rb -timestamp=.rbconfig.time -install_name=ruby -so_name=ruby rbconfig.rb
|
| Breakpoint 1, garbage_collect () at gc.c:1295
| 1295 SET_STACK_END;
| (gdb) p *(NODE * volatile) 0x401c7b4c
| $4 = {flags = 132127, nd_file = 0x813db39 "./mkconfig.rb", u1 = {
| node = 0x401c7bc4, id = 1075608516, value = 1075608516,
| cfunc = 0x401c7bc4, tbl = 0x401c7bc4}, u2 = {node = 0x401c3dbc,
| id = 1075592636, argc = 1075592636, value = 1075592636}, u3 = {
| node = 0x401c7b38, id = 1075608376, state = 1075608376,
| entry = 0x401c7b38, cnt = 1075608376, value = 1075608376}}
GC が起きたときには問題の NODE は生きている
| (gdb) finish
| Run till exit from #0 garbage_collect () at gc.c:1295
| rb_gc () at gc.c:1406
| 1406 rb_gc_finalize_deferred();
| (gdb) p *(NODE * volatile) 0x401c7b4c
| $5 = {flags = 0, nd_file = 0x401c7b38 "", u1 = {node = 0x401c7bc4,
| id = 1075608516, value = 1075608516, cfunc = 0x401c7bc4,
| tbl = 0x401c7bc4}, u2 = {node = 0x401c3dbc, id = 1075592636,
| argc = 1075592636, value = 1075592636}, u3 = {node = 0x401c7b38,
| id = 1075608376, state = 1075608376, entry = 0x401c7b38, cnt = 1075608376,
| value = 1075608376}}
GC が終ると回収されてしまっている
| (gdb) c
| Continuing.
| : [BUG] unknown node type 0
| ruby 1.9.0 (2004-12-13) [i686-linux]
|
|
| Program received signal SIGABRT, Aborted.
| 0x4009e6b1 in kill () from /lib/libc.so.6
| (gdb) p *(NODE * volatile) 0x401c7b4c
| $6 = {flags = 0, nd_file = 0x401c7b38 "", u1 = {node = 0x401c7bc4,
| id = 1075608516, value = 1075608516, cfunc = 0x401c7bc4,
| tbl = 0x401c7bc4}, u2 = {node = 0x401c3dbc, id = 1075592636,
| argc = 1075592636, value = 1075592636}, u3 = {node = 0x401c7b38,
| id = 1075608376, state = 1075608376, entry = 0x401c7b38, cnt = 1075608376,
| value = 1075608376}}
| (gdb) up
| #1 0x4009e435 in raise () from /lib/libc.so.6
| (gdb)
| #2 0x4009f978 in abort () from /lib/libc.so.6
| (gdb)
| #3 0x080d58d6 in rb_bug (fmt=0x0) at error.c:214
| 214 abort();
| (gdb)
| #4 0x0805b4bd in rb_eval (self=1075673536, n=0x0) at eval.c:3868
| 3868 rb_bug("unknown node type %d", nd_type(node));
| (gdb) p node
| $7 = (NODE * volatile) 0x401c7b4c
最初の実行とアドレスが代わっていないことを確認する
| (gdb) up
| #5 0x08055dfd in ruby_exec_internal () at eval.c:1470
| 1470 eval_node(ruby_top_self, ruby_eval_tree);
| (gdb) p ruby_eval_tree
| $8 = (NODE *) 0x401c7b4c
| (gdb)
というわけで、ruby_eval_tree が GC の root になってないんじゃないかと
予想すると実際にそのとおりでなっていません。
過去をひもとくと、
Wed Sep 22 09:04:41 2004 Yukihiro Matsumoto <matz@ruby-lang.org>
* parse.y: remove global variables ruby_eval_tree and
ruby_eval_tree_begin.
というところで削除されたという記録が見つかります。そのときの変更は
[ruby-cvs:12752] で、
|matz Wed, 22 Sep 2004 09:19:16 +0900
|
| Modified files:
| ruby:
| ruby.c parse.y node.h intern.h hash.c eval.c array.c ChangeLog
| Log:
| * parse.y: remove global variables ruby_eval_tree and
| ruby_eval_tree_begin.
|
| * array.c (rb_ary_collect_bang): element size might change during
| comparison. [ruby-dev:24300]
|
| * array.c (rb_ary_reject_bang): ditto. [ruby-dev:24300]
|
| * array.c (rb_ary_eql): ditto. [ruby-dev:24300]
|
| Revision Changes Path
| 1.93 +16 -13 ruby/ruby.c
| http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/ruby.c?cvsroot=src&r1=1.92&r2=1.93
| 1.344 +41 -36 ruby/parse.y
| http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/parse.y?cvsroot=src&r1=1.343&r2=1.344
| 1.56 +4 -2 ruby/node.h
| http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/node.h?cvsroot=src&r1=1.55&r2=1.56
| 1.151 +1 -3 ruby/intern.h
| http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/intern.h?cvsroot=src&r1=1.150&r2=1.151
| 1.135 +2 -2 ruby/hash.c
| http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/hash.c?cvsroot=src&r1=1.134&r2=1.135
| 1.698 +9 -13 ruby/eval.c
| http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/eval.c?cvsroot=src&r1=1.697&r2=1.698
| 1.157 +14 -15 ruby/array.c
| http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/array.c?cvsroot=src&r1=1.156&r2=1.157
| 1.3529 +17 -0 ruby/ChangeLog
| http://www.ruby-lang.org/cgi-bin/cvsweb.cgi/ruby/ChangeLog?cvsroot=src&r1=1.3528&r2=1.3529
というものです。コードの変更をみるとたしかに log のとおりに parse.y か
らは消えているのですが、log に書かれていない ruby.c と eval.c の変更も
あります。そして、eval.c では
rb_global_variable((VALUE*)&ruby_eval_tree);
という行が削除されているのですが、ruby_eval_tree という変数自体は残っ
ています。実際、現在でも次のようにオブジェクトに入っています。
% nm ruby.o|grep ruby_eval_tree
00000004 C ruby_eval_tree
% nm eval.o|grep ruby_eval_tree
U ruby_eval_tree
rb_global_variable が消えているということからは ruby_eval_tree を全部
消す意図が感じられるのですが、実際には残っていて何かに使われているわけ
で、どうも怪しげな感じがします。実際の所、このへんの変更は意図通りなん
でしょうか?
--
[田中 哲][たなか あきら][Tanaka Akira]