[#34556] /(.)(.)/.match("ab").select {|v| true } is empty — Tanaka Akira <akr@...>
以下のように、MatchData#select でブロックが常に真なのに結果
[#34567] write to broken pipe on Linux — Nobuyoshi Nakada <nobu@...>
なかだです。
まつもと ゆきひろです
なかだです。
[#34571] Re: [ruby-cvs:23495] Ruby:r16255 (ruby_1_8, trunk): * range.c (range_step): allow float step bigger than zero but less — Tanaka Akira <akr@...>
In article <200805011435.m41EZFBL003014@ci.ruby-lang.org>,
[#34605] Array#mapがEnumeratorを返さない — rubikitch@...
るびきちです。
[#34623] Marshal.load( Marshal.dump( Float ) )の不一致@1.8 — "H.Holon" <holon@...>
H.Holonです。
[#34646] break in lambda — Tanaka Akira <akr@...>
lambda 直下に break があったとき、なにごともなかったかのよう
[#34647] fork 不可能な環境での test_argv0_noarg — wanabe <s.wanabe@...>
ワナベと申します。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
須藤です。
[#34648] Bignum のメソッドからの bigzero_p — wanabe <s.wanabe@...>
ワナベと申します。
[#34676] removing Array#nitems {} — "Akinori MUSHA" <knu@...>
Array#nitems はnilでない要素を数えるメソッドですが、ブロックを
[#34691] ext/openssl and newer OpenSSL — Takahiro Kambe <taca@...>
こんにちは。
[#34692] [ruby1.9] fork と thread — Hidetoshi NAGAI <nagai@...>
永井@知能.九工大です.
[#34726] memory leak by Array#sort! — Tanaka Akira <akr@...>
以下のように、Array#sort! の中で配列を変更するとメモりリークします。
[#34739] net/imap uses Thread#raise — Tanaka Akira <akr@...>
net/imap が原因だと思うのですが、
前田です。
In article <704d5db90805210204o7aa80c00lfeb13a34230c2c03@mail.gmail.com>,
なかだです。
[#34741] Date.parse("##-##-##") — "Akinori MUSHA" <knu@...>
Date.parse("##.##.##") の ruby_1_8 における挙動が trunk とも
> Date.parse("##.##.##") の ruby_1_8 における挙動が trunk とも
[#34742] Ruby 1.8.7-preview3 has been released — "Akinori MUSHA" <knu@...>
Ruby 1.8.7-preview3 をリリースしました。
お疲れ様です。
At Mon, 19 May 2008 11:28:10 +0900,
In message <86k5hrow30.knu@iDaemons.org>
もう一つ追加です。
At Mon, 19 May 2008 18:55:42 +0900,
[#34751] benchmark result of reverse_complement — SASADA Koichi <ko1@...>
ささだです.
[#34758] Re: [ruby-cvs:23717] Ruby:r16477 (trunk): * regparse.c (PINC): use optimized enclen() instead of — SASADA Koichi <ko1@...>
ささだです.
遠藤と申します。
[#34768] Improvement of lazy sweep patch — authorNari <authornari@...>
authorNariです。
まつもと ゆきひろです
[#34775] (1..5).step(SimpleDelegator.new(1.5)) {|x| p x} differ from (1..5).step(1.5) {|x| p x} — Tanaka Akira <akr@...>
以下のように (1..5).step(1.5) {|x| p x} と
[#34800] Windows2000上でtrunkがビルドできない — KIMURA Koichi <kimura.koichi@...>
木村です。
こんにちは、なかむら(う)です。
木村です。
木村です。
こんにちは、なかむら(う)です。
木村です。
こんにちは、なかむら(う)です。
[#34810] -Wall — SASADA Koichi <ko1@...>
ささだです.
[#34830] return value of pp — "Yusuke ENDOH" <mame@...>
遠藤です。
[#34877] [Ruby 1.9 - Bug #11] prelude.c compilation problem on mswin32 — redmine@...
Issue #11 has been updated by Usaku NAKAMURA.
[#34883] [#19002] RUBY_* constants — Kazuhiro NISHIYAMA <zn@...>
西山和広です。
[#34889] Ruby 1.8.7-preview4 test-all failed in OpenSSL::TestSSL — Nobuhiro IMAI <nov@...>
いまいです。
Nobuhiro IMAI さんは書きました:
At Sat, 31 May 2008 21:06:47 +0900,
この話題についていろいろ試していて気付いたのですが
[ruby-dev:34874] Invalid read may occur when raising an exception to a thread that waits for mutex
遠藤です。
以下のようにするとハングすることがあります。
$ ./ruby -ve '
N = 10
m = [Mutex.new]
m.first.lock
t = Thread.new do
begin
m.first.lock # (1)
rescue
loop { } # (3)
end
end
sleep 1
t.raise # (2)
m.clear
sleep 1
GC.start # (4)
t.raise # (5)
'
ruby 1.9.0 (2008-05-28 revision 16675) [i686-linux]
^Z
流れはこんな感じです。
- (1) でスレッド t の unblock_function が lock_interrupt に
なり、mutex の解放待ちに入る。
- (2) でスレッド t の unblock_function (= lock_interrupt) が
呼ばれる。
- スレッド t の unblock_function はクリアされるべきだが、
クリアされないままスレッド t の実行は (3) に移る。
- (4) で mutex を free する (ただし環境依存) 。
- (5) でスレッド t の unblock_function (= lock_interrupt) が
呼ばれるが、lock_interrupt の中で解放済みの mutex に触る。
実際、valgrind にかけると、lock_interrupt 内で Invalid read
しているのがわかります。
==15890== Invalid read of size 4
==15890== at 0x811AA87: lock_interrupt (thread.c:2439)
==15890== by 0x81181D9: rb_thread_interrupt (thread.c:222)
==15890== by 0x8119284: rb_thread_ready (thread.c:864)
==15890== by 0x81192EE: rb_thread_raise (thread.c:884)
==15890== by 0x811941F: thread_raise_m (thread.c:960)
==15890== by 0x810A59B: call_cfunc (vm_insnhelper.c:286)
==15890== by 0x8114F32: vm_call_cfunc (vm_insnhelper.c:376)
==15890== by 0x8114A7C: vm_call_method (vm_insnhelper.c:508)
==15890== by 0x8110F8B: vm_eval (insns.def:1048)
==15890== by 0x8115135: vm_eval_body (vm.c:1022)
==15890== by 0x811575C: rb_iseq_eval (vm.c:1226)
==15890== by 0x805A0FB: ruby_exec_node (eval.c:221)
==15890== Address 0x44B6F04 is 76 bytes inside a block of size 80 free'd
==15890== at 0x401CFA5: free (vg_replace_malloc.c:233)
==15890== by 0x805EA4E: ruby_xfree (gc.c:425)
==15890== by 0x811A899: mutex_free (thread.c:2340)
==15890== by 0x80606C4: obj_free (gc.c:1498)
==15890== by 0x8060214: gc_sweep (gc.c:1371)
==15890== by 0x8060B0C: garbage_collect (gc.c:1704)
==15890== by 0x80614AF: rb_gc (gc.c:2119)
==15890== by 0x8060B6B: rb_gc_start (gc.c:1751)
==15890== by 0x810A5B1: call_cfunc (vm_insnhelper.c:289)
==15890== by 0x8114F32: vm_call_cfunc (vm_insnhelper.c:376)
==15890== by 0x8114A7C: vm_call_method (vm_insnhelper.c:508)
==15890== by 0x8110F8B: vm_eval (insns.def:1048)
unblock_function がクリアされないのは set_unblock_function 内で
RUBY_VM_CHECK_INTS をしていて、そこから longjmp するせいです。
この RUBY_VM_CHECK_INTS は必要なんでしょうか。
Index: thread.c
===================================================================
--- thread.c (revision 16676)
+++ thread.c (working copy)
@@ -197,19 +197,11 @@
set_unblock_function(rb_thread_t *th, rb_unblock_function_t *func, void *arg,
rb_unblock_function_t **oldfunc, void **oldarg)
{
- check_ints:
- RUBY_VM_CHECK_INTS(); /* check signal or so */
native_mutex_lock(&th->interrupt_lock);
- if (th->interrupt_flag) {
- native_mutex_unlock(&th->interrupt_lock);
- goto check_ints;
- }
- else {
- if (oldfunc) *oldfunc = th->unblock_function;
- if (oldarg) *oldarg = th->unblock_function_arg;
- th->unblock_function = func;
- th->unblock_function_arg = arg;
- }
+ if (oldfunc) *oldfunc = th->unblock_function;
+ if (oldarg) *oldarg = th->unblock_function_arg;
+ th->unblock_function = func;
+ th->unblock_function_arg = arg;
native_mutex_unlock(&th->interrupt_lock);
}
--
Yusuke ENDOH <mame@tsg.ne.jp>