JavaObject.wrap synchronizing on the java instance can cause deadlock
---------------------------------------------------------------------
Key: JRUBY-1559
URL: http://jira.codehaus.org/browse/JRUBY-1559
Project: JRuby
Issue Type: Bug
Components: Java Integration
Affects Versions: JRuby 1.1b1, JRuby 1.0.2, JRuby 1.0.1, JRuby 1.0.0
Environment: OS X Leopard / Tiger
Windows Vista / XP / 2000
Linux
Java 1.5.x and 1.6.x
JRuby 1.0, 1.0.1, 1.0.2, 1.1b and edge
Reporter: Micah Alles
Priority: Critical
Fix For: JRuby 1.0.3, JRuby 1.1
Attachments: deadlock.tgz, java_object_wrap_locking.diff
In JavaObject.wrap(...) a RubyObject is created which corresponds to an
instance of a java object. The java instance is currently used to synchronize
access to the cached RubyObjects.
Synchronizing on the java instance can be inherently dangerous due to the
common practice in java of declaring public methods synchronized and using
non-private instances for synchronized blocks.
This problem has affected our development of a desktop application when using
the Batik library through jruby. One of the classes which is a part of their
public API followed the practice described above of using publicly available
objects as a monitor for synchronization. The combination of that practice and
the way JavaObject.wrap was locking on the same java instance caused periodic
deadlock in our application.
I've included a patch and a small sample project with a test case which results
in deadlock with the current JavaObject.wrap implementation and successfully
runs to completion with the patch applied. The patch synchronizes on the
RubyObject wrapper instance instead of the java instance.
To run the test from within the included project:
{{rake test jruby=path/to/jruby}}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
