[#44469] [Ruby 1.9 - Bug #5279][Open] $SAFEが3以上の時にString#encodeがSecurityErrorを発生させるケースがある — Shota Fukumori <sorah@...>

21 messages 2011/09/06
[#44471] [Ruby 1.9 - Bug #5279] $SAFEが3以上の時にString#encodeがSecurityErrorを発生させるケースがある — Shota Fukumori <sorah@...> 2011/09/06

[#44472] Re: [Ruby 1.9 - Bug #5279] $SAFEが3以上の時にString#encodeがSecurityErrorを発生させるケースがある — "NARUSE, Yui" <naruse@...> 2011/09/06

2011年9月6日11:02 Shota Fukumori <sorah@tubusu.net>:

[#44473] Re: [Ruby 1.9 - Bug #5279] $SAFEが3以上の時にString#encodeがSecurityErrorを発生させるケースがある — "Shota Fukumori (sora_h)" <sorah@...> 2011/09/06

じゃぁ,大丈夫かな.

[#44474] Re: [Ruby 1.9 - Bug #5279] $SAFEが3以上の時にString#encodeがSecurityErrorを発生させるケースがある — Kazuhiko <kazuhiko@...> 2011/09/06

On 06/09/2011 06:10, Shota Fukumori (sora_h) wrote:

[#44541] Re: [Ruby 1.9 - Bug #5279] $SAFEが3以上の時にString#encodeがSecurityErrorを発生させるケースがある — Kazuhiko <kazuhiko@...> 2011/09/24

かずひこです。

[#44549] Re: [Ruby 1.9 - Bug #5279] $SAFEが3以上の時にString#encodeがSecurityErrorを発生させるケースがある — KOSAKI Motohiro <kosaki.motohiro@...> 2011/09/26

> かずひこです。

[#44491] [Ruby 1.9 - Feature #5314][Open] パッケージマネージャをコアリリースに含めて欲しい — Taro MURAOKA <koron.kaoriya@...>

13 messages 2011/09/13

[#44506] [Ruby 1.9 - Feature #5317][Open] rubyのヘッダファイルを使った拡張を行う際にuid_tの宣言回避をする事が出来ない。 — Yasuhiro Matsumoto <mattn.jp@...>

9 messages 2011/09/13

[#44520] [Ruby 1.9 - Bug #5350][Open] WeakRef で謎の NoMethodError — Makoto Kishimoto <redmine@...>

20 messages 2011/09/21

[#44542] [Ruby 1.9 - Bug #5363][Open] OpenSSL::ASN1.decode_all の引数に PEM 形式の証明書を指定すると Segmentation fault が発生する — Hiroshi Yoshida <hexa.diary@...>

8 messages 2011/09/25

[#44546] [Ruby 1.9 - Bug #5368][Open] ensure節でsleepするようなThreadがあるとインタプリタが終了しない — Masaki Matsushita <glass.saga@...>

22 messages 2011/09/26

[ruby-dev:44536] Re: [ruby-dev:44535] Re: [ruby-dev:44534] Re: [ruby-dev:44532] [Ruby 1.9 - Bug #5350] WeakRef で謎の NoMethodError

From: SASADA Koichi <ko1@...>
Date: 2011-09-24 01:58:41 UTC
List: ruby-dev #44536
 ささだです.

(2011/09/23 18:47), Shota Fukumori (sora_h) wrote:
> 元の問題がややこしくなっているので一旦まとめると,
> 
> a = Object.new
> mutex = Mutex.new # finalizer と共有している mutex
> 
> ObjectSpace.define_finalizer(a) { # (1) a に対する finalizer
>   mutex.synchronize { p "ho" }    # (2) ここでロックしようとするが, (3) と
>                                   # 同じスレッドなので ThreadError 例外発生
>                                   # (例外の発生は rescue で確認可能)
> }
> mutex.synchronize { # (3)
>   a = nil
>   GC.start
>   p "hi"
>   loop{ Object.new } # このループ中で (1) で定義した finalizer が呼ばれる
> }
> 
> このようなサンプルコードを実行したときに (3) の mutex.synchronize 中に
> オブジェクト a が解放された後,何らかのタイミングで a に対する finalizer
> (1) が実行されると, (3) で mutex がロックされたまま同じスレッド (?) で
> 再び (2) で Mutex#lock を試みるため ThreadError "dead lock; recursive
> locking" (thread.c:3555) が発生しています.
> 
> で,この問題に対する解決策は
> 
> 1. これは仕様という事にしてしまう
>    → これが採用された場合,Glass_saga の GC.disable と GC.enable を挟む
> パッチ
>    を取り込んで解決の方向?
> 2. その他何らかの良い方法

 問題のまとめをありがとうございます.

 ファイナライザの実行は,何時起こるかわからないものなので,デッドロック
の可能性がある処理を行うのは,プログラムが悪い,ということになります.基
本的には,デッドロックを起こさないように書き直す必要がありますが,例えば
上記の場合では,mutex.trylock を利用することで回避することができます.


# 本質的に,何かしら他の対処が必要な話だろうか?

-- 
// SASADA Koichi at atdot dot net

In This Thread