[#23357] [Feature #1432] decrement and increment — Oleg Puchinin <redmine@...>
Feature #1432: decrement and increment
[#23372] [Bug #1438] dylib architecture error building 1.9.1-rc2 on osx10.5.6 — Matthew Moss <redmine@...>
Bug #1438: dylib architecture error building 1.9.1-rc2 on osx10.5.6
[#23402] [Bug #1448] [patch] Proper handling of recursive arrays — Marc-Andre Lafortune <redmine@...>
Bug #1448: [patch] Proper handling of recursive arrays
[#23449] Submit bugs against 1.9.1? — Robert Klemme <shortcutter@...>
Hi there,
[#23457] [Bug #1471] "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7 — John Carter <redmine@...>
Bug #1471: "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7
[#23464] [Feature #1473] Improvements on expect.rb — Luiz Angelo Daros de Luca <redmine@...>
Feature #1473: Improvements on expect.rb
[#23483] [Bug #1478] Ruby archive — Oleg Puchinin <redmine@...>
Bug #1478: Ruby archive
Issue #1478 has been updated by Luis Lavena.
Issue #1478 has been updated by Luis Lavena.
On Fri, Apr 2, 2010 at 17:13, Luis Lavena <redmine@ruby-lang.org> wrote:
> Thanks for your comment.
OK Hiroshi, I read some of the comments earlier in the thread that I
On 5/20/10, Jonathan Nielsen <jonathan@jmnet.us> wrote:
Hi,
(2010/05/22 19:58), Benoit Daloze wrote:
On 22 May 2010 18:40, Urabe Shyouhei wrote:
(2010/05/23 2:38), Benoit Daloze wrote:
On Sat, May 22, 2010 at 1:21 PM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:
[#23491] [Bug #1482] Kernel.exec doesn't respect COMSPEC environment variable on Windows — Evgeniy Dolzhenko <redmine@...>
Bug #1482: Kernel.exec doesn't respect COMSPEC environment variable on Windows
[#23492] [Bug #1484] Ruby 1.8.6_p368 and Ruby 1.8.7_p160 have threading regressions — Hans de Graaff <redmine@...>
Bug #1484: Ruby 1.8.6_p368 and Ruby 1.8.7_p160 have threading regressions
[#23499] [Bug #1487] String#each_char must return self — Marc-Andre Lafortune <redmine@...>
Bug #1487: String#each_char must return self
Hi,
On Sat, 23 May 2009 10:20:50 +0900
[#23501] [Bug #1490] DateTime::civil fails with second=59 and fractional second > 0 — Paul Harris <redmine@...>
Bug #1490: DateTime::civil fails with second=59 and fractional second > 0
[#23505] [Bug #1494] tempfile#unlink may silently fail on windows — Nicholas Manning <redmine@...>
Bug #1494: tempfile#unlink may silently fail on windows
Issue #1494 has been updated by Shyouhei Urabe.
Issue #1494 has been updated by Hongli Lai.
[#23520] [Bug #1504] installed ri docu is not where ri actually searches when compiled with program-suffix — Yuki Sonoda <redmine@...>
Bug #1504: installed ri docu is not where ri actually searches when compiled with program-suffix
[#23538] [ANN] RubyKaigi2009: Commiter Invitation — SASADA Koichi <ko1@...>
Hi,
[#23543] a feature for ruby: Kernel#in? — Roger Pack <rogerdpack@...>
Following a discussion on ruby-talk of a few ideas for ruby[1],
Excerpts from rogerdpack's message of Mon May 25 07:41:36 +0300 2009:
> I am pretty opposed to adding #in?; however, it is currently
[#23572] [Bug #1525] Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork? — Hongli Lai <redmine@...>
Bug #1525: Deadlock in Ruby 1.9's VM caused by ConditionVariable.wait and fork?
Issue #1525 has been updated by Eric Wong.
Issue #1525 has been updated by Vanja Bucic.
On Jul 21, 2009, at 9:06 PM, Vanja Bucic wrote:
Issue #1525 has been updated by Vanja Bucic.
Vanja Bucic wrote:
none < wrote:
Issue #1525 has been updated by Nobuyoshi Nakada.
In article <4b03c299d3778_4360404660a1be@redmine.ruby-lang.org>,
In article <87einw55ej.fsf@fsij.org>,
Tanaka Akira wrote:
[#23584] [Bug #1528] setlocale is not initialized causing problems when using iconv — Hans de Graaff <redmine@...>
Bug #1528: setlocale is not initialized causing problems when using iconv
[#23593] Defining #name= at the class level — Gregory Brown <gregory.t.brown@...>
Hi folks,
Hi,
Excerpts from Yukihiro Matsumoto's message of Fri May 29 01:21:19 +0300 2009:
Hi,
[#23595] Meaning of RUBY_PLATFORM — Rick DeNatale <rick.denatale@...>
The RUBY_PLATFORM constant is documented in the latest Pickaxe as "The
On Thu, May 28, 2009 at 3:41 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
On Thu, May 28, 2009 at 2:52 PM, Luis Lavena <luislavena@gmail.com> wrote:
On Thu, May 28, 2009 at 7:08 PM, Rick DeNatale <rick.denatale@gmail.com> wrote:
On Thu, May 28, 2009 at 7:22 PM, Luis Lavena <luislavena@gmail.com> wrote:
> 1) The guy who wrote the gem fell into the trap of assuming that
Roger Pack wrote:
[#23614] [Bug #1535] Hash#merge! Inside Iterator Can Cause RuntimeError — Run Paint Run Run <redmine@...>
Bug #1535: Hash#merge! Inside Iterator Can Cause RuntimeError
[#23630] Expected Behaviour of Modifying an Iterator in the Block to Which it Yields? — Run Paint Run Run <runrun@...>
Hi,
[#23636] feature request: Directory.dir? — Roger Pack <rogerdpack@...>
For some reason it seems odd to have to do File.dir?
[#23639] [Bug #1541] mingw ssl: Errno::ENOTSOCK: An operation was attempted on something that is not a socket. — Roger Pack <redmine@...>
Bug #1541: mingw ssl: Errno::ENOTSOCK: An operation was attempted on something that is not a socket.
Issue #1541 has been updated by Roger Pack.
[#23644] [Bug #1545] Patches for the Hash Documentation — Run Paint Run Run <redmine@...>
Bug #1545: Patches for the Hash Documentation
Excerpts from message of Sun May 31 06:38:54 +0300 2009:
[#23646] Counterpart to File.extname — Martin DeMello <martindemello@...>
File.extname ought to have a complementary method that gets everything
On Sun, May 31, 2009 at 1:52 AM, Martin DeMello <martindemello@gmail.com> wrote:
On Mon, 1 Jun 2009 03:35:47 +0900
On Mon, Jun 1, 2009 at 6:11 AM, Michael Fellinger <m.fellinger@gmail.com> wrote:
[ruby-core:23457] [Bug #1471] "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7
Bug #1471: "Mutual join" deadlock detection faulty in 1.8.6 and 1.8.7
http://redmine.ruby-lang.org/issues/show/1471
Author: John Carter
Status: Open, Priority: Normal
Category: core
ruby -v: ruby 1.8.7 (2009-04-08 patchlevel 160) [i686-linux]
If a third thread is involved, the code in eval.c in function
rb_thread_join0 to detect a mutual join dead lock is faulty.
This effects ruby 1.8.6 p368 and ruby 1.8.7 p 160 but not ruby 1.9.1 p
129
What seems to be happening is a sequence like this....
main thread grabs mutex
thread two blocks waiting for mutex
thread one blocks waiting for mutex and th->join is set to the main thread.
the main thread unlocks, which wakes thread two. Thread two now has mutex, thread one is still blocked.
the main thread attempts to join thread one, rb_thread_join0 notes
that thread one is in a WAIT_JOIN waitfor state AND th->join still
points at the main thread and (erroneously) reports deadlock.
ruby-1.8.7-p160/eval.c================================================
rb_thread_join0(th, limit)
rb_thread_t th;
double limit;
{
enum rb_thread_status last_status = THREAD_RUNNABLE;
if (rb_thread_critical) rb_thread_deadlock();
if (!rb_thread_dead(th)) {
if (th == curr_thread)
rb_raise(rb_eThreadError, "thread 0x%lx tried to join itself",
th->thread);
if ((th->wait_for & WAIT_JOIN) && th->join == curr_thread)
rb_raise(rb_eThreadError, "Thread#join: deadlock 0x%lx - mutual join(0x%lx)",
curr_thread->thread, th->thread);
======================================================================
Affected versions.
/opt/ruby/ruby-1.8.6-p368/bin/ruby -v
ruby 1.8.6 (2009-03-31 patchlevel 368) [i686-linux]
/opt/ruby/ruby-1.8.7-p160/bin/ruby -v
ruby 1.8.7 (2009-04-08 patchlevel 160) [i686-linux]
Here is a test script to trigger it....
=mutual_join_bug.rb============================================================
require 'thread'
m = Mutex.new
m.lock
wt2 = Thread.new do
m.lock
sleep 2
m.unlock
end
# Ensure wt2 is waiting on m
sleep 0.1
wt1 = Thread.new do
m.lock
m.unlock
end
# Ensure wt1 is waiting on m
sleep 0.1
# Give it to wt2
m.unlock
wt1.join
======================================================================
Output...
/opt/ruby/ruby-1.8.7-p160/bin/ruby -w mutual_join_bug.rb mutual_join_bug.rb:24:in `join': Thread#join: deadlock 0xb7daa1bc - mutual join(0xb7d9bc48) (ThreadError)
from mutual_join_bug.rb:24
The following patch "fixes" it...
======================================================================
--- eval.c_orig 2009-03-23 22:28:31.000000000 +1300
+++ eval.c 2009-05-15 15:15:34.141270568 +1200
@@ -11426,9 +11426,13 @@
if (th == curr_thread)
rb_raise(rb_eThreadError, "thread 0x%lx tried to join itself",
th->thread);
+/* This test for mutual join deadlock is faulty in that
+ it doesn't allow for the possibility that a third thread
+ may now hold the mutex.
if ((th->wait_for & WAIT_JOIN) && th->join == curr_thread)
rb_raise(rb_eThreadError, "Thread#join: deadlock 0x%lx - mutual join(0x%lx)",
curr_thread->thread, th->thread);
+*/
if (curr_thread->status == THREAD_TO_KILL)
last_status = THREAD_TO_KILL;
if (limit == 0) return Qfalse;
======================================================================
But I'm not sure it is the correct fix. I'm still experience some
strangeness which I haven't pinned down yet.
I would seem to me that the correct fix is when a mutex is unlocked,
and then locked by some other thread, the th->join pointers of all
threads waiting on that mutex should be updated to point at the thread
now holding the mutex.
----------------------------------------
http://redmine.ruby-lang.org