Twitterを介したリモートデバッグの実例
-
yukihiro_matz
- 11515
- 0
- 33
- 5
-
- いいね！5
まつもとりー / Ryosuke Matsumoto
@matsumotory
さてmod_mrubyに復帰しようと思って早速コンパイルしてみたら、mrb_code *pc = irep->iseq;でmod_mrubyがsegfaultおこすようになってるな。
2012-09-03 10:24:55
まつもとりー / Ryosuke Matsumoto
@matsumotory
mod_mrubyここでこけるなぁ。 mrb_run (mrb=0xb57f8148, proc=0xb57fb01c, self=...) at vm.c:446 446 mrb_code *pc = irep->iseq;
2012-09-07 21:35:13
Yukihiro Matz
@yukihiro_matz
@matsumotory ここでirepの値はどうなってますか？ あるいはirep->iseqの値は？
2012-09-07 21:54:17
まつもとりー / Ryosuke Matsumoto
@matsumotory
@yukihiro_matz procが{tt = MRB_TT_PROC, color = 2, flags = 0, c = 0xb57fe6c4, gcnext = 0x0, body = {irep = 0x0, func = 0}, でirepはNULLになっています。
2012-09-07 22:07:34
Yukihiro Matz
@yukihiro_matz
@matsumotory irepが0なのはaliasかな。バックとレースはどうなってます？ トップレベルのmrb_runですか？ それともmrb_funcall_* 経由で呼ばれてますか？ その場合のmidは？
2012-09-07 22:10:06
まつもとりー / Ryosuke Matsumoto
@matsumotory
@yukihiro_matz mrb_runですね。#0 mrb_run (mrb=0xb57f8148, proc=0xb57fb01c, self=...) at vm.c:446
2012-09-07 22:14:39
Yukihiro Matz
@yukihiro_matz
@matsumotory ということは、トップレベルのmrb_runの先頭でいきなり落ちていると思ってよいでしょうか。ということは、最初のmrb_runの呼び出しでのprocの指定が間違っているようですね。バックトレース見れますか？
2012-09-07 22:28:30
まつもとりー / Ryosuke Matsumoto
@matsumotory
@yukihiro_matz 実装的にも先頭でいきなり落ちていると思われます。segfault後のバックトレースは https://t.co/tfb803Q6
2012-09-07 22:41:02
Yukihiro Matz
@yukihiro_matz
@matsumotory mod_mruby.c:995でのnの値が知りたいです。mrb_generate_code()の仕様が変わってたかも。
2012-09-07 22:56:16
まつもとりー / Ryosuke Matsumoto
@matsumotory
@yukihiro_matz nは148です。 995 mrb_run(mrb, mrb_proc_new(mrb, mrb->irep[n]), mrb_nil_value()); (gdb) p n $1 = 148
2012-09-07 22:58:17
Yukihiro Matz
@yukihiro_matz
@matsumotory mod_ruby.c:911のmrb_generate_code()の第２引数をp->treeからpに変更してみてください。引数の型が変わってます。
2012-09-07 22:58:47
Yukihiro Matz
@yukihiro_matz
@matsumotory あと、mrb_runの第３引数はmrb_top_self(mrb)の方が良いと思います。
2012-09-07 23:01:04