Bug #2371

[BUG] thread_free: locking _mutex must be NULL

Added by Chris Schlaeger over 5 years ago. Updated over 4 years ago.

[ruby-core:26745]
Status:Closed
Priority:Normal
Assignee:-
ruby -v:ruby 1.9.2dev (2009-11-10 trunk 25704) [x86_64-linux] Backport:

Description

=begin
During the development of a project management application I encountered the following problem. Every 10th run or so, the ruby interpreter crashes with the error message in the subject. I've attached a full backtrace in the log file. I've tried to reproduce the problem with a smaller test case, but without success. Sorry for that!

Here is how to reproduce the problem:

  1. Download the taskjuggler gem: http://www.taskjuggler.org/tj3/taskjuggler-0.0.3.gem and install it
  2. change to the 'examples' directory that comes with the gem or download tutorial.tjp from http://www.taskjuggler.org/tj3/examples/tutorial.tjp
  3. while /bin/true ; do tj3 -c 3 tutorial.tjp || break; done

The -c N option should be set slightly higher than the number of CPU cores in the system.
The program works fine with ruby 1.8.7 PL27.
=end

log Magnifier - Backtrace (1.3 KB) Chris Schlaeger, 11/15/2009 05:26 PM

History

#1 Updated by Yusuke Endoh over 5 years ago

=begin
Hi --

2009/11/15 Chris Schlaeger redmine@ruby-lang.org:

Here is how to reproduce the problem:

  1. Download the taskjuggler gem: http://www.taskjuggler.org/tj3/taskjuggler-0.0.3.gem and install it
  2. change to the 'examples' directory that comes with the gem or download tutorial.tjp from http://www.taskjuggler.org/tj3/examples/tutorial.tjp
  3. while /bin/true ; do tj3 -c 3 tutorial.tjp || break; done

The -c N option should be set slightly higher than the number of CPU cores in the system.
The program works fine with ruby 1.8.7 PL27.

Thank you for your report! Duplicated.

A smaller test case:

m = Mutex.new
Thread.new { m.lock; sleep }
sleep 0.2
Thread.new { sleep 0.2; fork { GC.start } }
m.lock

The following patch should fix the issue. Could you try?

diff --git a/thread.c b/thread.c
index ba717bd..5ea1982 100644
--- a/thread.c
+++ b/thread.c
@@ -380,6 +380,7 @@ thread_cleanup_func(void *th_ptr)
rb_mutex_unlock_all(th->keeping_mutexes, th);
th->keeping_mutexes = NULL;
}
+ th->locking_mutex = Qfalse;
thread_cleanup_func_before_exec(th_ptr);
native_thread_destroy(th);
}

--
Yusuke ENDOH mame@tsg.ne.jp

=end

#2 Updated by Chris Schlaeger over 5 years ago

=begin
Thanks for the very quick response!

The following patch should fix the issue.  Could you try?

Sure.

diff --git a/thread.c b/thread.c
index ba717bd..5ea1982 100644
--- a/thread.c
+++ b/thread.c
@@ -380,6 +380,7 @@ thread_cleanup_func(void *th_ptr)
       rb_mutex_unlock_all(th->keeping_mutexes, th);
       th->keeping_mutexes = NULL;
    }
+    th->locking_mutex = Qfalse;
    thread_cleanup_func_before_exec(th_ptr);
    native_thread_destroy(th);
 }

Yes, I can confirm that this patch fixes the problem. It also fixes
bug #2370 which seems to be just a different looking problem with the
same cause.

Chris

=end

#3 Updated by Yusuke Endoh over 5 years ago

  • Status changed from Open to Closed
  • % Done changed from 0 to 100

=begin
This issue was solved with changeset r25771.
Chris, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end

Also available in: Atom PDF