Such is the case if you embed JRuby into an application dynamically (such as via OSGi). From my test environment: ``` irb(main):006:0> $LOADED_FEATURES.grep(/cli.rb/) => ["uri:classloader:/META-INF/jruby.home/lib/ruby/stdlib/bundler/cli...ccutrer (Cody Cutrer)
I'm not exactly sure what's going on here, but the end result is basically a thread is getting killed unexpectedly during a waitpid call, when SIGCHLD is being handled. In a more complex scenario, we end up hanging because Thread#join is...ccutrer (Cody Cutrer)
~~~ruby module Calculations def pluck puts "calculations" end end module Calculations2 def pluck puts "calculations2" super end end class Relation include Calculations end Relation.prepend(Calc...ccutrer (Cody Cutrer)
In a certain situation, Exception#cause can become an infinite list: ```ruby def raise_errors begin raise "error 1" ensure orig_error = $! begin raise "error 2" rescue => err raise orig_er...ccutrer (Cody Cutrer)
I can confirm that this is working on current master, but with one problem - if the exception is ever rescued and then re-raised (even with just a plain `raise`, not `raise e` or anything), the backtrace is reset to where it's re-raised ...ccutrer (Cody Cutrer)
There is no documentation for `hash` that if you override it, you should not use instance variables. Either this needs to be prevented by ruby, or the documentation needs to be updated. The actual case that triggered this was `ActiveReco...ccutrer (Cody Cutrer)
If a user class redefines hash to something that depends on instance variables, and the object is loaded both before a hash, and as a key of a hash of one of its own instance variables (that's loaded *before* the instance variables neede...ccutrer (Cody Cutrer)