From: nagachika00@...
Date: 2015-05-26T07:45:30+00:00
Subject: [ruby-core:69358] [Ruby trunk - Bug #10644] [Rejected] WEBrick TimeoutHandler race condition

Issue #10644 has been updated by Tomoyuki Chikanaga.

Status changed from Open to Rejected

Hello,

The definition of WEBrick::Utils::TimeoutHandler#initialize in your gist is too old and the issues was already fixed at r35258.

See https://github.com/ruby/ruby/blob/v2_1_5/lib/webrick/utils.rb#L168 and https://github.com/ruby/ruby/commit/7b18633804c606e8bcccfbb44e7d7b795e777ea6

----------------------------------------
Bug #10644: WEBrick TimeoutHandler race condition
https://bugs.ruby-lang.org/issues/10644#change-52631

* Author: Alan Da Costa
* Status: Rejected
* Priority: Normal
* Assignee: 
* ruby -v: 2.1.5
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
I discovered what looks like a race in the WEBrick TimeoutHandler. 

In WEBrick::Utils::TimeoutHandler#initialize, every 0.5 seconds, @timeout_info is iterated.

If WEBrick::Utils::TimeoutHandler.register is called when @timeout_info is being iterated, it results in a RuntimeError of "can't add a new key into hash during iteration (RuntimeError)"

I've created a gist to demonstrate the issue, https://gist.github.com/adacosta/65358efeb970ac84ca75 . In my gist, the initialize method has been augmented to stall the @timeout_info iteration, to help demonstrate the problem.

I've also noted a potential fix as wrapping the @timeout_info iteration with a TimeoutMutex.synchronize {} . I'll gladly package my fix into a patch if desired.

Thoughts?



-- 
https://bugs.ruby-lang.org/