[#25035] 拡張ライブラリへの共有ライブラリのPATHの埋め込み — Takahiro Kambe <taca@...>

こんにちは。

16 messages 2004/12/03
[#25070] Re: 拡張ライブラリへの共有ライブラリのPATHの埋め込み — nobu@... 2004/12/06

なかだです。

[#25071] Re: 拡張ライブラリへの共有ライブラリのPATHの埋め込み — Takahiro Kambe <taca@...> 2004/12/06

In message <200412060607.iB667giF007533@sharui.nakada.niregi.kanuma.tochigi.jp>

[#25089] Re: 拡張ライブラリへの共有ライブラリのPATHの埋め込み — nobu@... 2004/12/07

なかだです。

[#25090] Re: 拡張ライブラリへの共有ライブラリのPATHの埋め込み — Takahiro Kambe <taca@...> 2004/12/07

In message <200412070015.iB70FAiF012770@sharui.nakada.niregi.kanuma.tochigi.jp>

[#25093] Re: 拡張ライブラリへの共有ライブラリのPATHの埋め込み — akira yamada / やまだあきら <akira@...> 2004/12/07

2004-12-07 (火) の 12:27 +0900 に Takahiro Kambe さんは書きました:

[#25041] temporal locking already locked string on simultaneous write — Tanaka Akira <akr@...17n.org>

同じ文字列をほぼ同時に IO に書き込むと、temporal locking already

13 messages 2004/12/04
[#25042] Re: temporal locking already locked string on simultaneous write — Yukihiro Matsumoto <matz@...> 2004/12/04

まつもと ゆきひろです

[#25043] Re: temporal locking already locked string on simultaneous write — Tanaka Akira <akr@...17n.org> 2004/12/04

In article <1102133507.339625.10453.nullmailer@x31.priv.netlab.jp>,

[#25096] double free problem — "Akinori MUSHA" <knu@...>

 ご無沙汰しております。

15 messages 2004/12/07
[#25099] Re: double free problem — Yukihiro Matsumoto <matz@...> 2004/12/07

Hi,

[#25101] non-stdio buffering — Tanaka Akira <akr@...17n.org>

えぇと、今回 1.9 でなにが起きたのかを私が把握している範囲でまとめてお

18 messages 2004/12/07

[#25152] 1.8 reopen problem with duplex popen — Tanaka Akira <akr@...17n.org>

次のように、1.8 で双方向 popen な IO を reopen するとエラーになること

11 messages 2004/12/10

[#25158] core dump on NetBSD 2.0 — Tanaka Akira <akr@...17n.org>

NetBSD 2.0 で次のようにすると core を吐きます。

18 messages 2004/12/11
[#25159] Re: core dump on NetBSD 2.0 — Tanaka Akira <akr@...17n.org> 2004/12/11

In article <87hdmsivva.fsf@serein.a02.aist.go.jp>,

[#25163] Re: core dump on NetBSD 2.0 — Tanaka Akira <akr@...17n.org> 2004/12/12

In article <87ekhwiv7g.fsf@serein.a02.aist.go.jp>,

[#25165] Re: core dump on NetBSD 2.0 — nobu@... 2004/12/13

なかだです。

[#25167] Re: core dump on NetBSD 2.0 — Tanaka Akira <akr@...17n.org> 2004/12/13

In article <200412130040.iBD0e8Qh003275@sharui.nakada.niregi.kanuma.tochigi.jp>,

[#25193] 1.8.2 release schedule — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

15 messages 2004/12/14

[#25299] Re: リリース準備 — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

20 messages 2004/12/24
[#25301] Re: リリース準備 — TAKAHASHI Masayoshi <maki@...> 2004/12/24

高橋征義です。

[#25302] test_readline.rb blocks on BSD again — GOTOU Yuuzou <gotoyuzo@...>

In message <20041223175402.3116FC6718@lithium.ruby-lang.org>,

15 messages 2004/12/24
[#25314] Re: test_readline.rb blocks on BSD again — GOTOU Yuuzou <gotoyuzo@...> 2004/12/24

In message <20041224.131211.846943951.gotoyuzo@sawara.does.notwork.org>,

[#25315] Re: test_readline.rb blocks on BSD again — Yukihiro Matsumoto <matz@...> 2004/12/24

まつもと ゆきひろです

[#25317] Re: test_readline.rb blocks on BSD again — WATANABE Hirofumi <eban@...> 2004/12/25

わたなべです。

[ruby-dev:25189] ruby_eval_tree

From: Tanaka Akira <akr@...17n.org>
Date: 2004-12-13 16:56:01 UTC
List: ruby-dev #25189
[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]

In This Thread

Prev Next