From: "NAKAMURA, Hiroshi" Date: 2003-02-24T22:46:52+09:00 Subject: [ruby-dev:19649] Re: SEGV at search_method in eval.c (PR#400) なひです。 > From: > Sent: Monday, February 24, 2003 5:24 PM > At Mon, 24 Feb 2003 16:16:29 +0900 (JST), > nakahiro@sarion.co.jp 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 , > 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 , 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強。。。）