[#41531] [Bug #3385] ext/dbm: accept various version of db — Takahiro Kambe <redmine@...>
Bug #3385: ext/dbm: accept various version of db
2010年6月3日23:38 Takahiro Kambe <redmine@ruby-lang.org>:
2011年11月12日8:14 Tanaka Akira <akr@fsij.org>:
[#41536] RUBY_DEBUG=gc_stress [FATAL] failed to allocate memory — Tanaka Akira <akr@...>
コンパイル時に RUBY_DEBUG_ENV というマクロを定義しておくと、
[#41543] [Bug #3398] 1.9.2 SEGV during test-all — Yuki Sonoda <redmine@...>
Bug #3398: 1.9.2 SEGV during test-all
[#41597] [Bug #3433] Error that occurs by BasicSocket#sendmsg — Masaya Tarui <redmine@...>
Bug #3433: Error that occurs by BasicSocket#sendmsg
[#41600] 質問・提案:cgi.rbの後継となるライブラリについて — Dice <tetradice@...>
Diceです。cgi.rbの後継ライブラリについて質問させてください。
藤岡です。
かくたにです。
藤岡さん、かくたにさん、返信ありがとうございます。
藤岡です。
Diceです。藤岡さん、返信ありがとうございます。
[#41610] [Bug #3443] requireが遅くなる — Yusuke Endoh <redmine@...>
Bug #3443: requireが遅くなる
[#41623] [Feature:trunk] argument delegation — Nobuyoshi Nakada <nobu@...>
なかだです。
遠藤です。
まつもと ゆきひろです
前田です。
[#41672] [Bug #3463] 1.9.2-preview3 で [BUG] gc_sweep(): unknown data type 0x0 — Tomoyuki Chikanaga <redmine@...>
チケット #3463 が更新されました。 (by Tomoyuki Chikanaga)
[#41674] [Bug #3464] win32ole failure load TYPELIB on mswin64 vista — sakiyama shin <redmine@...>
Bug #3464: win32ole failure load TYPELIB on mswin64 vista
[#41702] WIN32OLE_METHOD offset_vtbl — kuwamoto shintaro <beuniv@...>
こんばんわ
助田です。
こんにちは、なかむら(う)です。
助田です。
artonです。
2010/6/24 arton <artonx@yahoo.co.jp>:
[#41705] [Bug #3471][Rejected] ./miniruby sample/test.rbで1NotOK — Shyouhei Urabe <redmine@...>
チケット #3471 が更新されました。 (by Shyouhei Urabe)
2010年6月24日16:53 Shyouhei Urabe <redmine@ruby-lang.org>:
[#41711] [Bug #3473] make clear-installed-list — Usaku NAKAMURA <redmine@...>
Bug #3473: make clear-installed-list
[#41730] (ruby/tk) ruby_1_9_2 への backport — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
[#41752] [Bug #3490][Assigned] test_pack_utf8 failure on mswin64 — Yusuke Endoh <redmine@...>
チケット #3490 が更新されました。 (by Yusuke Endoh)
[#41760] Hash[] の引数が Array の場合の振る舞い — とみたまさひろ <tommy@...>
とみたです。
[ruby-dev:41677] Re: [Bug #3463] 1.9.2-preview3 で [BUG] gc_sweep(): unknown data type 0x0
近永と申します。
パッチのレビューありがとうございます。
(2010/06/22 21:02), Nobuyoshi Nakada wrote:
(snip)
> finaliser_at_exitの時点では、新しいオブジェクトが割り当てられる
> ことは考えなくてもいいんじゃないかと思いますが。
clear_dump_arg に arg->str の flags が 0 で来てた時は、下のような
コールスタックでした。普通にメソッド呼び出しの間に遅延された
free 関数の呼び出しが挟み込まれているようです。
ところで、単に興味から訊いてみたいのですが、なぜこのように
T_DATA型オブジェクトの解放は遅延されてるんでしょう。
GC での停止時間を分散させるためでしょうか?
#0 clear_dump_arg (arg=0xa9f63c0) at marshal.c:856
#1 0x0807cec2 in free_dump_arg (ptr=0xa9f63c0) at marshal.c:175
#2 0x080641ad in run_final (objspace=0x9829808, obj=167215020) at gc.c:2601
#3 0x08062a17 in finalize_list (objspace=0x9829808, p=0x9f77fac) at gc.c:1806
#4 0x0806422a in finalize_deferred (objspace=0x9829808) at gc.c:2617
#5 0x0806423d in gc_finalize_deferred (objspace=0x9829808) at gc.c:2624
#6 0x08064263 in rb_gc_finalize_deferred () at gc.c:2631
#7 0x0814922c in rb_threadptr_execute_interrupts_rec (th=0xb5023148,
sched_depth=0) at thread.c:1295
#8 0x08149312 in rb_threadptr_execute_interrupts (th=0xb5023148)
at thread.c:1323
#9 0x081354e3 in vm_call_method (th=0xb5023148, cfp=0xb6bfe980, num=0,
blockptr=0x0, flag=0, id=784, me=0x9869b60, recv=7538958)
at vm_insnhelper.c:669
#10 0x081394c3 in vm_exec_core (th=0xb5023148, initial=0) at insns.def:999
#11 0x0814418d in vm_exec (th=0xb5023148) at vm.c:1139
Chikanaga Tomoyuki
Nippon Control System Corp.