トップ «前の日記(2010-04-17) 最新 次の日記(2010-04-21)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|

ToDo:


2010-04-18

_ てすと

てすと

(02:47)

_ leaks

ひさしぶりに ruby を rmemcheck にかけてみた… 対象は test/ruby で。

これは昔リークゼロにできてたようなそうでもなかったような。 もはや記憶になくて、記憶にないのは良くないので とりあえずここに記録を残して置いてみよう。

http://shinh.skr.jp/t/leaks.txt

特に何もしないプログラムでも Init_VM と Init_sym で リークが検知されるけど、 まぁこれは問題ないんじゃないかな。 前者は INSTRUCTION_NAMES とかで 後者は register_symid とか。 なんかでもこれ leaks.txt には書いてないな謎。

ていうか発生個所が単体で走らせると結構 leaks.txt と違ったりして謎。

とりあえず test_m17n_comb.rb は何かがおかしそうだ。

==19285== 39,982 (32,480 direct, 7,502 indirect) bytes in 70 blocks are definitely lost in loss record 63 of 68
==19285== Ruby /usr/local/lib/ruby/1.9.1/minitest/unit.rb:176
==19285==    at 0x4C255D3: malloc (mc_replace_strmem.c:1127)
==19285==    by 0x49737D: onig_new (regcomp.c:5600)
==19285==    by 0x489D4C: rb_reg_prepare_re (re.c:1259)
==19285==    by 0x489F4F: T.591 (re.c:1318)
==19285==    by 0x48A724: rb_reg_match (re.c:2703)
==19285==    by 0x512496: vm_call_method (vm_insnhelper.c:377)
==19285==    by 0x513B85: vm_exec_core (insns.def:1002)
==19285==    by 0x5183F8: vm_exec (vm.c:1133)
==19285==    by 0x5199B5: rb_yield (vm.c:586)
==19285==    by 0x52A954: rb_ary_each (array.c:1413)
==19285==    by 0x512496: vm_call_method (vm_insnhelper.c:377)
==19285==    by 0x513B85: vm_exec_core (insns.def:1002)

これは re.c の

   if (tmpreg) {
       if (RREGEXP(re)->usecnt) {
           onig_free(reg);
       }
       else {
           onig_free(RREGEXP(re)->ptr);
           RREGEXP(re)->ptr = reg;
       }
   }

を適当に

   if (tmpreg) {
       onig_free(reg);
   }

とかにしたら消えた気がする。 しかし RREGEXP(re)->ptr はそもそも解放されてないような気がするのが謎で謎。

とりあえず最小テストケース

d = "foobar"
d.force_encoding("EUC-JP")
/./ =~ d

というあたりで飽きた

(03:06)

本日のツッコミ(全2件) [ツッコミを入れる]
_ naruse (2014-05-24 05:33)

gc.cの以下で解放されてませんか
      case T_REGEXP:
        if (RANY(obj)->as.regexp.ptr) {
            onig_free(RANY(obj)->as.regexp.ptr);
        }
        break;

_ shinh (2014-05-24 05:33)

ああそこなんですね。なんか僕の記憶が確かなら tmpreg なら必ず onig_free するようにいじった場合も、その後 RREGEXP(re)->pnt は onig_free されてなかったもののリークだと捕捉されてなかった気がするので、ええと不思議ですね。なんか変数入ってない正規表現リテラルは最初にだけ初期化してた気がするので、まぁなんかそうやって作られたやつは解放されない感じになってるんですかねえ。だとしても途中で中身交換する時だけリークだと言われるのも謎ですが。

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2010年
4月
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30
1.naruse(2014-05-24 05:33) 2.kosaki(2014-05-24 05:33) 3.shinh(2014-05-24 05:33)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h