My IRB gem kills Rails

Hi all, I released a gem for IRB the other day and somebody sent me a
screencast of it killing Rails:

http://screencast.com/t/k6Nlk8Q0Csy

(As an aside, I think screencasts are the coolest way to do a bug
report.)

He has a Rails app running; he installs my gem; he restarts his
server; he gets an error in one of the my_model_url methods, i.e.,
model_path(my_model) fails for him as a result of installing a gem
which is only required in his .irbrc, and not anywhere in his
application.

A little while back, before I put it all in a gem, I had a lot of code
in my .irbrc, and I frequently would see "Constant already
initialized" errors showing up in my Rails logs for constants that
were only specified in my .irbrc and not used anywhere else.

Consequently I very much suspect Rails is somehow picking up
people's .irbrc files in its load path, and I kinda suspect it's a
bug. I'm going to see if I can fix it, but I just thought I'd check
here first to see if anybody has any idea where it might be coming
from. (I don't know a thing about the internals of the Rails load
sequence yet.) Any and all help muchly appreciated.

Giles

breakpoint.rb requires irb so it may be coming from that (or at least it used to)…

Actually, the error isn't in Rails itself as far as I can tell. As you can see in the screencast @module becomes nil, which could point to the fact that it's never set in the controller, which is understandable as utility belt probably uses a lot magic to create stuff like the finder shortcuts.

It's possible that it has something to do with IRB and reading the .irbrc, but as far as I know it's only used through ruby-debug now.

Can you find out…
- …what version of Rails he's using.
- …what is in his .irbrc.
- …what happens when he removes the .irbrc.

And after that create a ticket about it?

Manfred

> He has a Rails app running; he installs my gem; he restarts his
> server; he gets an error in one of the my_model_url methods, i.e.,
> model_path(my_model) fails for him as a result of installing a gem
> which is only required in his .irbrc, and not anywhere in his
> application.

Actually, the error isn't in Rails itself as far as I can tell. As you
can see in the screencast @module becomes nil, which could point to
the fact that it's never set in the controller, which is
understandable as utility belt probably uses a lot magic to create
stuff like the finder shortcuts.

OK, I don't get that at all. He's got the page working; he loads
Utility Belt; the page breaks. The fact that he had the page working
indicates he probably did have @module set to a value before that
point. He unloads Utility Belt and reloads the page with no difficult,
which means that @module probably gets a value again.

Utility Belt doesn't really use very much magic in the finder
shortcuts. It does use a Proc to load *after* IRB loads, but the
finder shortcuts themselves don't even use reflection, they just glob
the app/models dir. That code comes from Mike Clark's blog so it's
really easy to check:

http://clarkware.com/cgi/blosxom/2007/09/03

I think it's fair to say the error might be in Rails when you're
loading an irrelevant gem and seeing a previously-working page
suddenly fail.

It's possible that it has something to do with IRB and reading
the .irbrc, but as far as I know it's only used through ruby-debug now.

Yes, I agree with you there.

Can you find out...
- ...what version of Rails he's using.
- ...what is in his .irbrc.
- ...what happens when he removes the .irbrc.

And after that create a ticket about it?

I never do that kind of thing. I'm going to find out how it broke, and
fix it, or I'm going to tell people to watch out for the bug in Rails.
Sorry. I was just hoping I could get some guidance towards which part
of the internals might contain the bug. But it's cool, I'll find it.
Thanks anyway.

Thanks especially (both you and Salmon) for the breakpoint/ruby-debug
tip.

Requesting more info from the bug-reporter, I noticed this:

I installed it, and didn't notice anything on my apps, or a brand new
rails one. It's not picking up any custom code I put in my .irbrc
file either. Be sure to list what plugins are loaded along with the
rails version of the affected app.

That’s true. Requiring irb has bitten us also in the past. If you want pre-Rails 2.0 compatibility for your gem you have to teach people either to turn off breakpointer or you’ll have to re-write some of your code.

Here is the email I sent to Dr. Nic when we debugged map_by_method killing Rails:

I found out where .irbrc is included. Stable
Rails apps have breakpoint_server set to “true” in dev mode. Well, that
option makes “breakpoint.rb” get included in the dispatcher, which in
turn requires IRB. Commenting out breakpoint_server in
environments/development.rb fixes everything.

This was a temporary workaround until we found out how map_by_method broke Rails in the first place.

I found out where .irbrc is included. Stable Rails apps have
breakpoint_server set to "true" in dev mode. Well, that option makes "
breakpoint.rb" get included in the dispatcher, which in turn requires IRB.
Commenting out breakpoint_server in environments/development.rb fixes
everything.

Fantastic! Thank you. You rawk.

Giles

I installed it, and didn't notice anything on my apps, or a brand newrailsone. It's not picking up any custom code I put in my .irbrc
file either. Be sure to list what plugins are loaded along with therailsversion of the affected app.

It's on a user's computer in either Portugal or Brazil, I'm guessing,
because they appear to use Portugese. What I'm actually checking out
for the future is a bug-reporty thing which would be a variation on
Tattle, the gem which profiled your system and reported to a server
which then compiled stats on the community. It should be possible to
scan vendor/plugins pretty easily in that code, when (or more
realistically if) I build it.

Giles

Looky what I found in the Acts As Statemachine plugin.

acts_as_statemachine/test/test_helper.rb:

...
require 'active_support/binding_of_caller'
require 'active_support/breakpoint'
...

Moral: Also double-check any other installed plugins.