Project

General

Profile

Bug #15262

Updated by larskanis (Lars Kanis) 7 months ago

Given the following program:

```ruby
require "weakref"

Thread.abort_on_exception = true

class Adder
def self.start_adder(obj, oid) self.start_adder(obj)
obj.add
end

def initialize
@qu = Queue.new
count @mutex = Mutex.new
@mutex.lock
begin
@count =
10
count.times

@count.times
do

Thread.new(WeakRef.new(self), object_id, &self.class.method(:start_adder))

end
count.times do ensure
@qu.pop @mutex.unlock
end
@qu.deq

end

def add
@qu.push @mutex.lock
begin
@count-=1
if @count == 0
@qu.enq
true
elsif @count < 0
raise "shouldn't happen"
end
ensure
@mutex.unlock
end

end
end

def test_adder
10.times.map do
Thread.new do
Adder.new
end
end.each(&:join)
end

1000.times 100.times do
test_adder
end
```

## Expected behaviour:

The program should simply execute without error. This is the case on JRuby but not on MRI.

## Actual behavior:

The program stops with a probability of approximately 50% 80% with the following error:
```
$ ruby -W2 adder-test.rb
#<Thread:0x0000556e9e06f3f8@adder-test2.rb:6 #<Thread:0x0000562d5089fea8@adder-test.rb:6 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
adder-test2.rb:7:in adder-test.rb:7:in `start_adder': Invalid Reference - probably recycled (WeakRef::RefError)
Traceback (most recent call last):
adder-test.rb:7:in `start_adder': Invalid Reference - probably recycled (WeakRef::RefError)
```

Although `start_adder` works with a `WeakRef`, the `Adder` object should still be GC marked and therefore kept usable per `WeakRef` until marked, since `Adder.new` exited. This is because `Adder.new` waits for completion of doesn't return before all Threads calls to have called `start_adder`. `start_adder` finished.

If `Adder.start_adder` is changed to catch the `WeakRef` error like so:

```ruby
def self.start_adder(obj, oid)
obj.add
rescue WeakRef::RefError
end
```

... then the ruby VM detects a deadlock, which shows that `@qu.pop` is still executed within `initialize`. Therefore `WeakRef#add` should not raise a `WeakRef::RefError` to that point in time, but allow access to the object:

```
Traceback (most recent call last):
5: from adder-test2.rb:35:in `<main>'
4: from adder-test2.rb:35:in `times'
3: from adder-test2.rb:36:in `block in <main>'
2: from adder-test2.rb:32:in `test_adder'
1: from adder-test2.rb:32:in `each'
adder-test2.rb:32:in `join': No live threads left. Deadlock? (fatal)
2 threads, 2 sleeps current:0x000056520aa3cee0 main thread:0x000056520a5f2ff0
* #<Thread:0x000056520a644b48 sleep_forever>
rb_thread_t:0x000056520a5f2ff0 native:0x00007f7ccf535740 int:0
adder-test2.rb:32:in `join'
adder-test2.rb:32:in `each'
adder-test2.rb:32:in `test_adder'
adder-test2.rb:36:in `block in <main>'
adder-test2.rb:35:in `times'
adder-test2.rb:35:in `<main>'
* #<Thread:0x000056520a913040@adder-test2.rb:29 sleep_forever>
rb_thread_t:0x000056520a609fc0 native:0x00007f7ca54d4700 int:0
depended by: tb_thread_id:0x000056520a5f2ff0
adder-test2.rb:18:in `pop'
adder-test2.rb:18:in `block in initialize'
adder-test2.rb:17:in `times'
adder-test2.rb:17:in `initialize'
adder-test2.rb:30:in `new'
adder-test2.rb:30:in `block (2 levels) in test_adder'
```

I verified this on ruby-trunk, but get mostly the same behavior on all older MRI versions.

Back