[ruby-dev:19649] Re: SEGV at search_method in eval.c (PR#400)

なひです。

> From: <[e-mail]>
> Sent: Monday, February 24, 2003 5:24 PM

> At Mon, 24 Feb 2003 16:16:29 +0900 (JST),
> [e-mail] wrote:
> > ruby/1.6で動いているRWikiのdaemonが、最近、
> > 起動後しばらくして（4時間とか）coreを吐くようになりました。
> > 時間なのか、もしくはdRubyでの通信の回数なのか、偶然なのかは
> > わかりません。
> >
> > ともあれ、起動してしばらくは何の問題もなく動き、そして
> > しばらくして落ちるというのを7回再現中なので、なひの環境では
> > 再現性がありそうです。
>
> GC絡みのような気がします。

とりあえずは適当にGC.startを入れて様子を見てみることにしました。
それとは別に、原因究明したいです。

> > stack traceは長いのでここにおいてあります。
> > http://rrr.jin.gr.jp/rwiki?cmd=view;name=ToDo320
> > 他に何か必要な情報はあるでしょうか。
>
> rubyのスタックトレースとか。

SEGVした瞬間のrubyのスタックトレースはどう取ればいいでしょうか。^^;

> #6  0x4002e4d9 in search_method (klass=135285569, id=8201, origin=0xbffeb940)
>     at eval.c:275
> #7  0x4002e522 in rb_get_method_body (klassp=0xbffeb974, idp=0xbffeb978,
>     noexp=0xbffeb968) at eval.c:293
> #8  0x4002e981 in rb_method_boundp (klass=135285569, id=8201, ex=0)
>     at eval.c:453
> #9  0x40035a09 in rb_respond_to (obj=1078229828, id=8201) at eval.c:3311
> #10 0x400527fe in w_object (obj=1078229828, arg=0xbffebbd8, limit=-3)
>     at marshal.c:325
>
> klassが奇数ということはないはずなので、#9の時点で既に1078229828
> のオブジェクトは壊れているようです。

なるほどー。

> #11 0x400525d3 in obj_each (id=10858, value=1078229828, arg=0xbffeba90)
>     at marshal.c:240
> #12 0x40087021 in st_foreach (table=0x8ab3220, func=0x400525a4 <obj_each>,
>     arg=0xbffeba90) at st.c:488
> #13 0x400526b5 in w_ivar (tbl=0x8ab3220, arg=0xbffeba90) at marshal.c:262
> #14 0x40052eb3 in w_object (obj=1078141208, arg=0xbffebbd8, limit=-2)
>     at marshal.c:494
>
> FL_EXIVARのオブジェクトをMarshal.dumpしようとしているようですが、
> 1078141208と1078229828のオブジェクトの中身はどうなってるでしょ
> う。

中身を見てみました。

$ gdb -c core-20030224-1 /home/nahi/bin/ruby
...
#0  0x4012ad41 in __kill () from /lib/libc.so.6
(gdb) bt
#0  0x4012ad41 in __kill () from /lib/libc.so.6
#1  0x4012a9b6 in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x4012c0d8 in abort () at ../sysdeps/generic/abort.c:88
#3  0x4002cb91 in rb_bug () at error.c:180
#4  0x40083ea4 in sigpipe (sig=11) at signal.c:393
#5  0x4012ac68 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#6  0x4002e4d9 in search_method (klass=135285569, id=8201, origin=0xbffeb940)
    at eval.c:275
#7  0x4002e522 in rb_get_method_body (klassp=0xbffeb974, idp=0xbffeb978,
    noexp=0xbffeb968) at eval.c:293
#8  0x4002e981 in rb_method_boundp (klass=135285569, id=8201, ex=0)
    at eval.c:453
#9  0x40035a09 in rb_respond_to (obj=1078229828, id=8201) at eval.c:3311
#10 0x400527fe in w_object (obj=1078229828, arg=0xbffebbd8, limit=-3)
    at marshal.c:325
#11 0x400525d3 in obj_each (id=10858, value=1078229828, arg=0xbffeba90)
    at marshal.c:240
#12 0x40087021 in st_foreach (table=0x8ab3220, func=0x400525a4 <obj_each>,
    arg=0xbffeba90 "虻??愡??????敢??椪\005@\030!C@愡??????・237\n@\210時須022w\003@婿??・237\n@愡??賍037C@・237\n@愡??賍037C@\210時
晋刷植) at st.c:488
#13 0x400526b5 in w_ivar (tbl=0x8ab3220, arg=0xbffeba90) at marshal.c:262
#14 0x40052eb3 in w_object (obj=1078141208, arg=0xbffebbd8, limit=-2)
    at marshal.c:494
#15 0x40052edc in dump (arg=0xbffebbcc) at marshal.c:502
...
(gdb) up 8
#8  0x4002e981 in rb_method_boundp (klass=135285569, id=8201, ex=0)
    at eval.c:453
453         if (rb_get_method_body(&klass, &id, &noex)) {
(gdb) p klass
$1 = 135285569
(gdb) up
#9  0x40035a09 in rb_respond_to (obj=1078229828, id=8201) at eval.c:3311
3311        if (rb_method_boundp(CLASS_OF(obj), id, 0)) {
(gdb) p obj
$2 = 0
(gdb) up
#10 0x400527fe in w_object (obj=1078229828, arg=0xbffebbd8, limit=-3)
    at marshal.c:325
325             if (rb_respond_to(obj, s_dump)) {
(gdb) p obj
$3 = 1078229828
(gdb) p (struct RClass)obj
$4 = {basic = {flags = 1078229828, klass = 3221141900}, iv_tbl = 0xbffeb984,
  m_tbl = 0x40035a09, super = 135285569}
(gdb) up 4
#14 0x40052eb3 in w_object (obj=1078141208, arg=0xbffebbd8, limit=-2)
    at marshal.c:494
494             w_ivar(ivtbl, &c_arg);
(gdb) p obj
$5 = 1078141208
(gdb) p (struct RClass)obj
$6 = {basic = {flags = 1078141208, klass = 3221142172}, iv_tbl = 0x40052eb3,
  m_tbl = 0x8ab3220, super = 3221142160}
(gdb)

「オブジェクトの中身」のより良い見方を教えてください。

他にもcoreが取ってあるので見てみます（どれも26M強。。。）