My IRB gem kills Rails

[giles bowkett]

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

[Saimon Moore]

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

-- 

Saimon Moore

Freelance Web Developer

(Available for hire - For details visit http://saimonmoore.net)

Skype: saimonmoore

Yahoo IM: saimonmoore

Google IM: saimonmoore

[Manfred Stienstra]

On Dec 16, 2007, at 1:29 AM, giles bowkett wrote:

> 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.

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

[giles bowkett]

On Dec 16, 1:48 am, Manfred Stienstra <manf...@gmail.com> wrote:
> On Dec 16, 2007, at 1:29 AM, giles bowkett wrote:
>
> > 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.

[giles bowkett]

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

> I just installed your utility belt on my laptop and it took
> a while to realize that it was causing a very strange behavior on some of my
> apps: The edit action on many controllers was not being executed.
****

Utility Belt adds a command-line method called "edit" to IRB. Adding
command-line methods in IRB really means adding methods to Object.
This supports my theory that Rails is loading Utility Belt by
requiring .irbrc (as does the anecdotal stuff about seeing "Constant
already initialized" errors for constants which were only used in
my .irbrc and nowhere else).

The weird part is that it suggests that the .irbrc must be mistakenly
loaded *after* the controller is defined (since if it happened before
the controller itself was loaded, the newer and more specific
definition of edit in the controller would override the older, more
general one in Object).

This is cool because it means I can probably change the name of my
method and get Rails compatibility. But it's not really Rails
compatibility, it's just dodging one frequent symptom of an underlying
problem which persists. So I'm going to see if I can find out more.
I'll submit a patch if I discover anything useful.

giles

[Rick Olson]

On Dec 16, 7:41 am, giles bowkett <gil...@gmail.com> wrote:
> Requesting more info from the bug-reporter, I noticed this:
>
> > I just installed your utility belt on my laptop and it took
> > a while to realize that it was causing a very strange behavior on some of my
> > apps: The edit action on many controllers was not being executed.

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.

[Mislav Marohnić]

On Dec 16, 2007 9:54 AM, Saimon Moore <saimo...@gmail.com> wrote:

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

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.

[Mislav Marohnić]

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.

[giles bowkett]

> 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

[giles bowkett]

> 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

[Saimon Moore]

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.

--