[#90865] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been reported by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90877] [Ruby trunk Bug#15499] Breaking behavior on ruby 2.6: rb_thread_call_without_gvl doesn't invoke unblock_function when used on the main thread — apolcyn@...
Issue #15499 has been updated by apolcyn (alex polcyn).
3 messages
2019/01/03
[#90895] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707)) — Eric Wong <normalperson@...>
ko1c-failure@atdot.net wrote:
4 messages
2019/01/05
[#90896] Re: [ruby-alerts:11680] failure alert on trunk-mjit@silicon-docker (NG (r66707))
— Takashi Kokubun <takashikkbn@...>
2019/01/05
Thanks to explain that.
[#91200] [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout — glass.saga@...
Issue #15553 has been reported by Glass_saga (Masaki Matsushita).
4 messages
2019/01/21
[#91289] Re: [Ruby trunk Feature#15553] Addrinfo.getaddrinfo supports timeout
— Eric Wong <normalperson@...>
2019/01/26
glass.saga@gmail.com wrote:
[ruby-core:90899] [Ruby trunk Bug#15508] Mutex recursive lock error when combined with Thread#raise
From:
lars@...
Date:
2019-01-05 18:06:52 UTC
List:
ruby-core #90899
Issue #15508 has been reported by larskanis (Lars Kanis).
----------------------------------------
Bug #15508: Mutex recursive lock error when combined with Thread#raise
https://bugs.ruby-lang.org/issues/15508
* Author: larskanis (Lars Kanis)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-linux]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
This is another issue I noticed with [Eventbox](https://github.com/larskanis/eventbox):
This script triggers sporadic error `deadlock; recursive locking (ThreadError)`:
```ruby
Thread.abort_on_exception = true
class Stop < RuntimeError
end
def go
mutex = Mutex.new
ths = 10.times.map do
Thread.handle_interrupt(Exception => :never) do
Thread.new do
begin
Thread.handle_interrupt(Stop => :on_blocking) do
mutex.synchronize{}
sleep
end
rescue Stop
end
mutex.synchronize{}
end
end
end
ths.each do |th|
th.raise Stop
end
ths.each(&:join)
end
100.times do
go
end
```
The program must be started in a loop, since it doesn't fail always. But if called in a while loop, typically aborts after some seconds like so:
```sh
$ while (ruby -d --disable-gems recursive-lock-error.rb ); do true; done
[...]
Exception `Stop' at recursive-lock-error.rb:15 - Stop
Exception `Stop' at recursive-lock-error.rb:15 - Stop
Exception `Stop' at recursive-lock-error.rb:14 - Stop
Exception `Stop' at recursive-lock-error.rb:14 - Stop
Exception `Stop' at recursive-lock-error.rb:14 - Stop
Exception `Stop' at recursive-lock-error.rb:14 - Stop
Exception `Stop' at recursive-lock-error.rb:15 - Stop
Exception `Stop' at recursive-lock-error.rb:14 - Stop
Exception `ThreadError' at recursive-lock-error.rb:19 - deadlock; recursive locking
#<Thread:0x0000560244102650@recursive-lock-error.rb:11 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
1: from recursive-lock-error.rb:19:in `block (3 levels) in go'
recursive-lock-error.rb:19:in `synchronize': deadlock; recursive locking (ThreadError)
```
According to my analysis it happens, that the `Stop` exception is sometimes delivered while `Mutex#lock` is running, but the mutex ownership isn't properly cleared. The next call to `Mutex#lock` then fails with `recursive locking` error.
This issue is present on ruby-2.5.3 and 2.6.0. Ruby-2.4 seems to be unaffected.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>