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.