[ruby-dev:19841] Re: SEGV on Rubicon with ruby -w

In article <[e-mail]>,
  [e-mail] writes:

> 案の定というか、やっぱり私のところでは起きませんでした。

まぁ、ありがちですね。

>> #6  0x08051a94 in search_method (klass=1075308160, id=43, origin=0xbfff3f44) at eval.c:299
>
> ここのところのklassの中身と
>
>> #9  0x08056831 in rb_eval (self=1075564536, n=0x401ed770) at eval.c:2833
>
> ここのselfの中身って分かりますか。

gdb 上で run すると SEGV しないので、がんばって生きているプロセスに繋
げてみました。
(あるウインドウで Rubicon を動かして、それが終了する前に attach するあ
たりが「がんばって」というところです。)

% gdb
gdb: Symbol `emacs_ctlx_keymap' has different size in shared object, consider re-linking
GNU gdb 2002-04-01-cvs
Copyright 2002 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".
(gdb) attach 12591
Attaching to process 12591
Reading symbols from /tmp/zzzzzzzzz/bin/ruby...done.
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x400d8e0d in malloc () from /lib/libc.so.6
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x080a7a01 in st_lookup (table=0x4017e680, key=43, value=0xbfff3ef8) at st.c:258
258         hash_val = do_hash(key, table);

というようにめでたく SEGV しているところを捕まえられて、klass を調べて
みるわけですが、

(gdb) up
#1  0x08051a94 in search_method (klass=1075308160, id=43, origin=0xbfff3f34) at eval.c:299
299         }
(gdb) p klass
$1 = 1075308160
(gdb) rp klass
Unknown

おや? Unknown といわれてしまいます。

(gdb) p *(struct RBasic *)klass
$2 = {flags = 0, klass = 4294967295}

中身を調べてみると、flags が 0 ということで謎です。
というわけでこれはあきらめて、つぎの self にいくと、

(gdb) up
#2  0x08051ad8 in rb_get_method_body (klassp=0xbfff3f84, idp=0xbfff3f74, noexp=0xbfff3f78) at eval.c:317
317         if ((body = search_method(klass, id, &origin)) == 0 || !body->nd_body) {
(gdb) 
#3  0x0805b7d4 in rb_call (klass=1075308160, recv=1075308168, mid=43, argc=1, argv=0xbfff3fa4, scope=0) at eval.c:4879
4879        else if ((body = rb_get_method_body(&klass, &id, &noex)) == 0) {
(gdb) 
#4  0x08056831 in rb_eval (self=1075564536, n=0x401ed770) at eval.c:2833
2833                result = rb_call(CLASS_OF(recv),recv,node->nd_mid,argc,argv,0);
(gdb) p self
$4 = 1075564536
(gdb) rp self
T_OBJECT
$5 = {basic = {flags = 2, klass = 1075748336}, iv_tbl = 0x8127f88}

T_OBJECT だそうですが、それだけではよくわかんないので、klass を調べて
みますと、

(gdb) rp 1075748336
T_CLASS
(gdb) rb_classname 1075748336
$6 = 1075748016
$7 = {basic = {flags = 3, klass = 1075748036}, iv_tbl = 0x816a450, m_tbl = 0x816a408, super = 1075748396}

となって、もとの(Rubicon を動かしたウインドウに) "Rubicon::TestRunner"
と出て来たので、きっと Rubicon::TestRunner のインスタンスだと思います。

>> ただ、かなり微妙な条件のようで、今のところ問題を絞り込めていません。
>> (少なくとも prefix の長さに依存することは分かっています。z の数がひと
>> つ多くても少なくても再現しません。)
>
> まぁGCがなんか絡んでるんでしょう。

なんかリンカが怪しい模様です。

どうにか他のマシンで再現させられないかと思って、いろいろ試したところ、
問題の出るマシンから必要なライブラリをコピーして chroot 環境を作って、
それを他のマシンに持って行くことによって再現に成功しました。
(したがって、メモリなどのハード的な問題ではないことが確認されたといっ
ていいと思います。)

で、ライブラリをいろいろ変えて試してみると、/lib/ld-linux.so.2 を問題
が出ないマシンのものに変えると問題が出なくなるので、そのへんが絡んでる
みたいです。

問題が出るマシンの ld-linux.so.2 は Debian の libc6 2.2.5-14.3 なんで
すが、最近 upgrade をさぼっていたためちょっと古めです。

Ruby とリンカのどちらの問題なのかは依然として不明ですが、どうやったら
確認できるかなぁ。
-- 
[田中 哲][たなか あきら][Tanaka Akira]