Infinite loop when Pry is enabled #55

bbbco opened this Issue Mar 15, 2012 · 7 comments

3 participants


I have been using Pry (an alternative to irb) to debug and develop my tests. When I integrated ci_reporter into my TestUnit output, anytime that the Pry binding.pry is referenced in my code to bring up pry inside the program, I get an infinite loop:

TypeError: wrong argument type CI::Reporter::OutputCapture (expected File)
from /home/brian/.rvm/gems/ree-1.8.7-2012.02@reverbnation/gems/pry- `readline'

Any ideas?


ci-reporter member

Wow, that's a good one! ci_reporter overrides and wraps $stdout and $stderr with OutputCapture, which is a DelegateClass(IO). I guess Pry is expecting a concrete instance of File somewhere in its code. Maybe this is a bug in pry, that's being too strict in what it expects?

You should be able to work around this by setting ENV['CI_CAPTURE'] = 'off' before running the test case, or alternatively you might be able to avoid the situation by setting $stdout, $stderr = STDOUT, STDERR right before invoking pry.


Thanks for the quick response!

Your suggestion to set $stdout, $stderr = STDOUT, STDERR before calling binding.pry seems to work well! The only downside is that the reporter stops recording output, and there doesn't seem to be a way to give it back. Oh well, that is ok, as I just need the ability to toggle pry on and off temporarily without modifying the actual test suites and ci_reporter requirements themselves.

You might want to add this fix to your readme page for future use!

ci-reporter member

Would you mind filing an issue on pry's tracker (referencing this one) to see if there's anything they can do on their end?

The only other fix I can see would be to make OutputCapture a subclass of File and add delegate logic there.


Just FYI, I did file an issue on Pry's tracker here: pry/pry#490


Just a quick note about my findings so far:

The problem is caused by the builtin readline library on ruby 1.8.7 (it seems to have been fixed by 1.9.2) that requires $stdout (and $stdin) to be a subclass of File.

It's probably hard to fix this at the Pry level (as it's unlikely we always want to clobber a user's custom $stdout/$stdin) but we may be able to come up with a heuristic function for when it's safe to do so.

ci-reporter member

Thanks for the investigation. If 1.8.7 requies them to be subclasses of File then I should probably address it here.


Thanks guys!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment