トップ «前の日(09-14) 最新 次の日(09-16)» 追記   RSS 1.0 FEED  

Journal InTime


2004-09-15 (Wed)

_ 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の値がおかしいようだ。 さて、だれが悪いのだろう。

Tags: mod_ruby Ruby
本日のツッコミ(全2件) [ツッコミを入れる]

_ まつもと [デバッガであちこちのぞいて見ないと何ともいえませんね。 GCのバグか拡張ライブラリのバグかどちらかでしょう。 個人的..]

_ shugo [私も後者を期待(失礼)してるんですが...。 (Debian的に)]


2005-09-15 (Thu)

_ PGP鍵の更新

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

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

本日のツッコミ(全2件) [ツッコミを入れる]

_ @@@@ [第三者にアドレス騙られて新しい鍵を先に登録されちゃうとサービス拒否攻撃が成立しませんかね。 あ、鍵を更新するときに..]

_ shugo [いずれにせよ、新しい鍵の信用性は署名で判断するしかないんじゃないですかねえ。]


2018-09-15 (Sat)

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

画像0

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

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

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

Tags: 250DUKE