Content preview: Hi, the following script works under MRI 1.9, but not
under
jruby 1.9 (but in jruby 1.8): require ‘thread’ […]
Content analysis details: (-2.9 points, 5.0 required)
pts rule name description
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-Cloudmark-Analysis: v=1.1
cv=tMVj8KYobzzX0EiRnC7vY2isLrCxFvdg4RrHWPZXwJ0= c=1 sm=0
a=CPlwVjms4CEA:10 a=LO5H2U17-3cA:10 a=IkcTkHD0fZMA:10
a=FS2zM0_MbYXDbMUJVIIA:9 a=QEXdDO2ut3YA:10
a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Lines: 93
List-Id: ruby-talk.ruby-lang.org
List-Software: fml [fml 4.0.3 release (20011202/4.0.3)]
List-Post: mailto:[email protected]
List-Owner: mailto:[email protected]
List-Help: mailto:[email protected]?body=help
List-Unsubscribe: mailto:[email protected]?body=unsubscribe
Received-SPF: none (Address does not pass the Sender Policy Framework)
SPF=FROM;
[email protected];
remoteip=::ffff:221.186.184.68;
remotehost=carbon.ruby-lang.org;
helo=carbon.ruby-lang.org;
receiver=eq4.andreas-s.net;
Hi,
the following script works under MRI 1.9, but not under jruby 1.9 (but
in jruby 1.8):
require ‘thread’
class MutexedBoolean
def initialize(initial_value)
@value = initial_value
@mutex = Mutex.new
end
def true?
@mutex.synchronize do
@value == true
end
end
end
threads = []
run = MutexedBoolean.new(true)
Thread.abort_on_exception = true
threads << Thread.new do
while run.true?
puts “1”
sleep 1
end
end
threads << Thread.new do
while run.true?
puts “2”
sleep 1
end
end
threads.each { |t| t.join }
Here’s the stacktrace I’m getting. Only the first thread runs:
Exception in thread “RubyThread-1: threadtest.rb:1”
java.lang.LinkageError: loader (instance of
org/jruby/util/JRubyClassLoader): attempted duplicate class definition
for name: “threadtest$block_0$RUBY$true?”
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
at
org.jruby.util.JRubyClassLoader.defineClass(JRubyClassLoader.java:76)
at
org.jruby.internal.runtime.methods.InvocationMethodFactory.endClassWithBytes(InvocationMethodFactory.java:1358)
at
org.jruby.internal.runtime.methods.InvocationMethodFactory.getBlockCallback19(InvocationMethodFactory.java:899)
at
org.jruby.javasupport.util.RuntimeHelpers.createBlockCallback19(RuntimeHelpers.java:177)
at
org.jruby.javasupport.util.RuntimeHelpers.createCompiledBlockBody19(RuntimeHelpers.java:292)
at
org.jruby.javasupport.util.RuntimeHelpers.createCompiledBlockBody19(RuntimeHelpers.java:282)
at
org.jruby.ast.executable.RuntimeCache.createBlockBody19(RuntimeCache.java:442)
at
org.jruby.ast.executable.RuntimeCache.getBlockBody19(RuntimeCache.java:85)
at
org.jruby.ast.executable.AbstractScript.getBlockBody190(AbstractScript.java:106)
at threadtest.method__2$RUBY$true_p_(threadtest.rb:9)
at
threadtest$method__2$RUBY$true_p_.call(threadtest$method__2$RUBY$true_p_:65535)
at
threadtest$method__2$RUBY$true_p_.call(threadtest$method__2$RUBY$true_p_:65535)
at
org.jruby.runtime.callsite.CachingCallSite.cacheAndCall(CachingCallSite.java:262)
at
org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:105)
at threadtest.block_2$RUBY$file(threadtest.rb:31)
at
threadtest$block_2$RUBY$file.call(threadtest$block_2$RUBY$file:65535)
at
org.jruby.runtime.CompiledBlock19.yield(CompiledBlock19.java:154)
at
org.jruby.runtime.CompiledBlock19.call(CompiledBlock19.java:82)
at org.jruby.runtime.Block.call(Block.java:89)
at org.jruby.RubyProc.call(RubyProc.java:268)
at org.jruby.RubyProc.call(RubyProc.java:232)
at
org.jruby.internal.runtime.RubyRunnable.run(RubyRunnable.java:95)
at java.lang.Thread.run(Thread.java:662)
If I remove the @mutex check in true?, it works in jruby 1.9.
thanks,
That’s wacked. Please file a bug at http://bugs.jruby.org. Looks like
a class name we’re generating internally is not getting handled
properly.
Content preview: On 03.06.2011 18:51, Charles Oliver N. wrote: >
That’s
wacked. Please file a bug at http://bugs.jruby.org. Looks like > a
class
name we’re generating internally is not getting handled > properly.
[…]
Content analysis details: (-2.9 points, 5.0 required)
pts rule name description
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-Cloudmark-Analysis: v=1.1
cv=FXfX1j538S0toKVv4AeTokQJ/Dr7x98IW2CddS+R9NE= c=1 sm=0
a=CPlwVjms4CEA:10 a=NhDwYgNWgr0A:10 a=IkcTkHD0fZMA:10 a=6UslqmEZAAAA:8
a=igIs2nfnAAAA:8 a=wDIOVaOzAGZ9ImPq11wA:9 a=QEXdDO2ut3YA:10
a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk
Lines: 8
List-Id: ruby-talk.ruby-lang.org
List-Software: fml [fml 4.0.3 release (20011202/4.0.3)]
List-Post: mailto:[email protected]
List-Owner: mailto:[email protected]
List-Help: mailto:[email protected]?body=help
List-Unsubscribe: mailto:[email protected]?body=unsubscribe
Received-SPF: none (Address does not pass the Sender Policy Framework)
SPF=FROM;
[email protected];
remoteip=::ffff:221.186.184.68;
remotehost=carbon.ruby-lang.org;
helo=carbon.ruby-lang.org;
receiver=eq4.andreas-s.net;
On 03.06.2011 18:51, Charles Oliver N. wrote:
That’s wacked. Please file a bug at http://bugs.jruby.org. Looks like
a class name we’re generating internally is not getting handled
properly.
You can find it here: http://jira.codehaus.org/browse/JRUBY-5850
Content preview: On 08.06.2011 09:30, Charles Oliver N. wrote: > On
Sun,
Jun 5, 2011 at 10:41 AM, Markus F.[email protected] wrote:
On
03.06.2011 18:51, Charles Oliver N. wrote: >>> That’s wacked.
Please
file a bug at http://bugs.jruby.org. Looks like >>> a class name
we’re generating
internally is not getting handled >>> properly. >> >> You can find
it here:
http://jira.codehaus.org/browse/JRUBY-5850 > > Fixed! Sorry I didn’t
update
the bug until now; couldn’t remember > where I’d seen this email
until today
[…]
Content analysis details: (-2.9 points, 5.0 required)
pts rule name description
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
-1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1%
[score: 0.0000]
X-Cloudmark-Analysis: v=1.1
cv=HQ3F56nxkum+cgCiDL7AXQpbvw7DWrWCBJRnYYnM0Zc= c=1 sm=0
a=CPlwVjms4CEA:10 a=NhDwYgNWgr0A:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10
a=6UslqmEZAAAA:8 a=igIs2nfnAAAA:8 a=5QJJPv5uMWqOpnVCMaYA:9
a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Lines: 19
List-Id: ruby-talk.ruby-lang.org
List-Software: fml [fml 4.0.3 release (20011202/4.0.3)]
List-Post: mailto:[email protected]
List-Owner: mailto:[email protected]
List-Help: mailto:[email protected]?body=help
List-Unsubscribe: mailto:[email protected]?body=unsubscribe
Received-SPF: none (Address does not pass the Sender Policy Framework)
SPF=FROM;
[email protected];
remoteip=::ffff:221.186.184.68;
remotehost=carbon.ruby-lang.org;
helo=carbon.ruby-lang.org;
receiver=eq4.andreas-s.net;
On 08.06.2011 09:30, Charles Oliver N. wrote:
On Sun, Jun 5, 2011 at 10:41 AM, Markus F.[email protected] wrote:
On 03.06.2011 18:51, Charles Oliver N. wrote:
That’s wacked. Please file a bug at http://bugs.jruby.org. Looks like
a class name we’re generating internally is not getting handled
properly.
You can find it here: http://jira.codehaus.org/browse/JRUBY-5850
Fixed! Sorry I didn’t update the bug until now; couldn’t remember
where I’d seen this email until today
I’m happy this is solved! You don’t happen to have a time frame for
1.6.3 release? 
thanks,
On Sun, Jun 5, 2011 at 10:41 AM, Markus F. [email protected]
wrote:
On 03.06.2011 18:51, Charles Oliver N. wrote:
That’s wacked. Please file a bug at http://bugs.jruby.org. Looks like
a class name we’re generating internally is not getting handled
properly.
You can find it here: http://jira.codehaus.org/browse/JRUBY-5850
Fixed! Sorry I didn’t update the bug until now; couldn’t remember
where I’d seen this email until today
On Wed, Jun 8, 2011 at 7:34 AM, Markus F. [email protected]
wrote:
I’m happy this is solved! You don’t happen to have a time frame for 1.6.3
release?
Soonish?