[#68137] improve semantics of manpages — "Anthony J. Bentley" <anthony@...>
Hi,
1 message
2015/02/17
[#68144] Re: Future of test suites for Ruby — Anthony Crumley <anthony.crumley@...>
FYI...
4 messages
2015/02/17
[#68343] [Ruby trunk - Bug #10916] [Open] What the Ruby? SegFault? — ruby@...
Issue #10916 has been reported by why do i need this acct just to create a bug report.
5 messages
2015/02/27
[#68373] Re: [Ruby trunk - Bug #10916] [Open] What the Ruby? SegFault?
— "Martin J. Dürst" <duerst@...>
2015/03/02
> * Author: why do i need this acct just to create a bug report
[#68358] [Ruby trunk - Bug #10902] require("enumerator") scans LOAD_PATH 2x on every invocation — ruby@...1.net
Issue #10902 has been updated by Aman Gupta.
3 messages
2015/02/28
[ruby-core:68226] [Ruby trunk - Bug #10443] Forking with contended mutex held can lead to deadlock in child process upon unlock
From:
nobu@...
Date:
2015-02-22 06:56:10 UTC
List:
ruby-core #68226
Issue #10443 has been updated by Nobuyoshi Nakada. Maybe, `thread_destroy_keeping_mutexes()` should be in thread_pthread.c. ---------------------------------------- Bug #10443: Forking with contended mutex held can lead to deadlock in child process upon unlock https://bugs.ruby-lang.org/issues/10443#change-51587 * Author: Ben Weintraub * Status: Open * Priority: Normal * Assignee: Motohiro KOSAKI * ruby -v: ruby 2.1.3p242 (2014-09-19 revision 47630) [x86_64-darwin13.0] * Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN ---------------------------------------- If a Ruby thread calls `Process.fork` while holding a Mutex (for example, within a `Mutex#synchronize` block) that is also concurrently being contended for by a background thread, the thread in the child process will occasionally be unable to unlock the mutex it was holding at the time of the fork, and will hang under `rb_mutex_unlock_th` when attempting to acquire `mutex->lock`. I've been able to reproduce this on Ruby 2.1.1 - 2.1.3 and 2.2.0-preview1 (haven't tried elsewhere yet). The attached test case demonstrates the issue, although it can take up to 20 minutes to hit a reproducing case. The test case will print one '.' each time it forks. Once it stops printing dots, it has hit this bug (the parent process is stuck in a call to `Process.wait`, and the child is stuck in `rb_mutex_unlock_th`). The test case consists of a global lock that is contended for by 10 background threads, in addition to the main thread, which acquires it, forks, and then releases it. ---Files-------------------------------- rb-mutex-unlock-fork-test.rb (372 Bytes) rb-mutex-unlock-fork-test.rb (339 Bytes) 0001-thread.c-reinitialize-keeping-mutexes-on-fork.patch (3.06 KB) -- https://bugs.ruby-lang.org/