Journal InTime

_ mod_rubyがささる

ruby_1_8ブランチのHEAD + Apache 2.0.50 + mod_ruby svn headの 組み合わせで、ささることがあるようだ。 gdbをアタッチしてbtしてみるも、よくわからず。 条件も特定できない。

(gdb) bt  
#0  0x403d0670 in mallopt () from /lib/tls/libc.so.6
#1  0x00000038 in ?? ()
#2  0x404938a8 in __after_morecore_hook () from /lib/tls/libc.so.6
...
#27 0x40714278 in __JCR_LIST__ () from /usr/local/lib/libruby1.8.2.so.1.8
#28 0x00000000 in ?? ()
#29 0x00009344 in ?? ()
#30 0xbfff6818 in ?? ()
#31 0x4069f347 in ruby_xmalloc (size=120) at gc.c:116

明日、まつもとさんに相談してみよう。

boronもこいつのせいかなあ。

追記:

以下のようなスクリプトでSEGVした。

#!/usr/bin/ruby -Ksd

require "webrick/cgi"
require "search/namazu"

class MyCGI < WEBrick::CGI
  def do_GET(req, res)
    100.times {
      result = Search::Namazu.search("ruby", ["/home/shugo/tmp/index"])
    }
    ary = []
    10000.times {
      ary.push(Object.new)
    }
    res["content-type"] = "text/plain"
    res.body = "hello"
  end
end

cgi = MyCGI.new
cgi.start

今度はまともなバックトレースが取れた。

(gdb) bt
#0  0x403c1741 in st_free_table (table=0x82024b8) at st.c:219
#1  0x40371f60 in obj_free (obj=1079314672) at gc.c:1153
#2  0x40371a39 in gc_sweep () at gc.c:1021
#3  0x40372479 in rb_gc () at gc.c:1387
#4  0x40370daa in rb_newobj () at gc.c:376
#5  0x403739d6 in hash_alloc (klass=1078233508) at hash.c:183
#6  0x40373a64 in rb_hash_new () at hash.c:195
#7  0x4056007e in result_make_fields (idxid=0, docid=75, field_list=1078070448)
    at namazu.c:373
#8  0x405601e3 in result_make_hlist (hlist=0xbfff9e68, fields=1078070448)
    at namazu.c:394
#9  0x405604ea in search_main (search_0=1078070428) at namazu.c:480
#10 0x4035b904 in rb_ensure (b_proc=0x405603a0 <search_main>, data1=3221200480,
    e_proc=0x40560610 <search_ensure>, data2=3221200480) at eval.c:5184
#11 0x405606aa in namazu_f_search (argc=1836017711, argv=0x6d6f682f,
    self=1079103052) at namazu.c:502

どうも、Search::Namazu.searchの中でGCが起きた時に落ちてるっぽい。

(gdb) list
214         int i;
215
216         for(i = 0; i < table->num_bins; i++) {
217             ptr = table->bins[i];
218             while (ptr != 0) {
219                 next = ptr->next;
220                 free(ptr);
221                 ptr = next;
222             }
223         }
(gdb) p ptr
$10 = (st_table_entry *) 0x6d6f682f
(gdb) p *ptr
Cannot access memory at address 0x6d6f682f

ptrの値がおかしいようだ。 さて、だれが悪いのだろう。

_ PGP鍵の更新

よく考えたら、公開鍵サーバに古い鍵で署名した新しい鍵を投げて、 古い鍵に署名していただいたみなさんに「新しい鍵を公開鍵サーバに 登録しましたので、新しい鍵に署名をして公開鍵サーバに登録して ください」というお願いメールを送信するだけでいい気がしてきた。

はじめて署名する時は、いきなり公開鍵サーバに送るよりも、メール で相手に署名した公開鍵を送って、そのメールアドレスの持ち主で あることを確認した方がよい(もちろん署名する前に免許証などの 確認はしておく)。しかし、有効期限が近付いた鍵を更新する(新しい 鍵を作る)という場合は、すでにメールアドレスの確認は前にしてある のだから、メールのやり取りは必要ない。 いきなり公開鍵サーバに登録してOKならぐっとラクになった気がする。

_ VORGUEフロントアクスルスペーサー

とりあえずフロントの異音は収まったものの、フロントディスクとキャリパーの隙間があまりにも狭いのが気になって、VORGUEのフロントアクスルスペーサーを取り寄せてもらった。

センターが出たおかげかカシマコートのおかげかフロントの回転が軽くなったような気がする。

これでパーツ代10000円は痛いけど、店先に並んでた390/250DUKE（2016年以前のモデル）を見てみたら3台中2台は同じような状態だったので、必要経費と思うしかない。