I've fixed a couple really tricky bugs the past week and I'd like more eyes on the changes:
"threadContextMap leaks RubyThread on death of adopted thread" http://jira.codehaus.org/browse/JRUBY-4264 Fixed in 364c41a on branch "jruby-4264" http://github.com/jruby/jruby/commit/364c41a1ead0666d217856347b1adf2b23d77a90 This one introduces a reference queue to ThreadService to clean up old (leaking, in embedded scenarios) RubyThread instances that accumulated one per new thread that enters a JRuby runtime. It seems to work fine, but given that there's no example case to exercise it I'm worried. Bonus points to come up with a test case that exercises it. "jirb_swing broken: JRuby picking wrong constructor, with no obvious work around" http://jira.codehaus.org/browse/JRUBY-4680 Fixed in c1672c4 http://github.com/jruby/jruby/commit/c1672c484dac3b59403d16db17c6fbb469d0878a This one required some enhancements to how we choose Java methods. Specifically, it now examines arguments one at a time, ranking better matches closer to the beginning of the argument list higher. The old logic (which is still used as a fallback, to handle varargs), scanned the args all at once, looking for an all "exact" match or an all "assignable" match and so on. This caused many methods to be equally valid, and so on different JVMs and different platforms a different method might be chosen. I'd like someone to just read through my logic and see if I did anything silly. It also needs a test case. "Java exceptions can't be rescued with "rescue Exception"" http://jira.codehaus.org/browse/JRUBY-4677 Fixed in 323ba1e http://github.com/jruby/jruby/commit/323ba1e629f578e916b0779c421f4fae43a8aece Follow-up fix in 091db96 http://github.com/jruby/jruby/commit/091db96e56a770487d412d2373f2be79f5f7a5e7 This one scares me quite a bit. Recently it was reported here on the mailing list that a Ruby "rescue Exception" was not rescuing Java exceptions. Obviously the spirit of "rescue Exception" is to rescue all exceptional cases, so that they can be handled in some reasonably graceful way. The result of not rescuing Java exceptions is that it wasn't possible for Ruby code to cover all possible exits from a body of code, and in the reporter's case ActiveRecord ended up going ahead and committing a transaction. The bug is bad, but I'm worried about the cure. Java exceptions are now examined and caught for all cases of "rescue Exception" or "rescue Object", which means it's possible for Ruby code to interfere with the propagation of those exceptions if it's not careful. It also meant that JRuby-internal exceptions had to be marked as "Unrescuable" so they would always propagate appropriately, or else things like catch/throw and non-local break/return would stop working right in the presence of "rescue Exception". Anyone who has a little time to help review the changes...I'd really appreciate it :) - Charlie --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
