Ruby on Rails | Screencasts | Download | Documentation | Weblog | Community | Source

Ticket #10896 (new defect)

Opened 1 year ago

Last modified 5 months ago

"SystemStackError stack level too deep" when "id" is primary key

Reported by: uglypercy Assigned to: core
Priority: normal Milestone: 2.x
Component: ActiveRecord Version: edge
Severity: major Keywords: SystemStackError, stack level too deep.
Cc: jason.barnabe@gmail.com

Description

Where the primary key of a model object is named "id", line 1939 of ActiveRecord source file "base.rb"

self.class.send(:define_read_method, :id, attr_name, column)

seems to make method named "id" on the model object's class, not on the model object. References to the method "id" on model objects thus invoke "method_missing" at "attribute_methods.rb" line 181, which calls "define_attribute_methods" if it was not already called. But "define_attribute_methods" intentionally avoids creating a definition for "id" as well. Thus "method_missing" goes into infinite recursion at line 194.

Note that this problem does not seem to exist in most other environments.

One workaround is to change line 193 of "attribute_methods.rb" to read

if false and self.class.primary_key.to_s == method_name

Environment: Rails 2.0.2, Cygwin ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-cygwin] under Windows XP SP3 RC1, MySQL 5.1.21.

Change History

01/22/08 22:42:12 changed by uglypercy

On

http://weblog.rubyonrails.org/2007/11/29/rails-2-0-release-candidate-2

User Maxime seems to have reported a very similar bug on 10 Dec 2007, though with no environment info.

Bug also seems present under ruby 1.8.6 (2007-03-13 patchlevel 0) [i686-darwin8.9.1], but not in ruby 1.8.6 (2007-09-24 patchlevel 111) [i386-freebsd6].

01/22/08 23:17:42 changed by uglypercy

Rails startup issuing "WARNING: You're using the Ruby-based MySQL library that ships with Rails. This library is not suited for production. Please install the C-based MySQL library instead (gem install mysql)." which could be related.

04/13/08 03:38:52 changed by vazilla

i have the same problem Enviroment: Rails 2.0.2, SQLite3, ruby 1.8.6 (2007-09-24 patchlevel 111) [i686-linux]

05/07/08 23:24:15 changed by jesseclark

  • summary changed from "SystemStackError" under Cygwin when "id" is primary key to "SystemStackError" when "id" is primary key.

I've been getting this same problem using: Rails 2.0.2, OS X 10.4.11, ruby 1.8.4 (2005-12-24) [i686-darwin8.9.1], MySQL

While trying to track down the issue in debugger I noticed that for me it is happening when calling the id attribute of models loaded as an association to another model.

For example in a User class which has_many UserBlogs:

(rdb:19) @user = User.find( 74 ) #<User id: 74, created_at: "2007-06-05 12:24:42", <snip> >

(rdb:19) ub = @user.user_blogs.first #<UserBlog id: 1, user_id: 74, name: "adsfalkjer", <snip> >

(rdb:19) ub.id SystemStackError Exception: stack level too deep

(rdb:19) ub = UserBlog.find 1 #<UserBlog id: 1, user_id: 74, name: "adsfalkjer", <snip> > (rdb:19) ub.id 1

Also, the error doesn't seem to happen the first time the attribute is accessed, ( i.e. I can load an action without error the first time but if I refresh the page the error occurs on the second and every subsequent view until I restart the server ).

I can provide a stack trace if desired.

05/07/08 23:35:42 changed by jesseclark

  • summary changed from "SystemStackError" when "id" is primary key to "SystemStackError stack level too deep" when "id" is primary key.

Also, this problem only occurs when config.cache_classes = false in the config.

05/16/08 14:39:02 changed by m_hijazee@yahoo.com

  • keywords set to SystemStackError, stack level too deep..
  • severity changed from normal to major.

I also faced the same problem on following configurations: * ruby 1.86 * Rails 2.02 * Ubuntu 7.04 * PostgreSQL 8.2

This problem only occurs in development environment while test and production work perfect. We can also provide the stack trace.

07/23/08 16:14:13 changed by steved3298

I just ran into this problem on Rails 2.1.0. Using Ruby 1.8.7 (2008-06-20 patchlevel 22) and SQLite 3.5.9 in ArchLinux.

The workaround in the original message has worked perfectly so far for me.

07/27/08 19:28:44 changed by blaxter

I don't think this is about environment, jesseclark has put important information about this issue.

I have a 1.2.6 application, and when i upgrade to 2.0.2 (or higher), this bug occurs. It's when you try to access an id attribute of some associated object (and only the second time, before the attributed methods has been generated already)

08/04/08 23:27:56 changed by jeremyolliver

Oddly enough, I've encountered this problem while upgrading from rails 2.0.2 to 2.1.0, It never showed up in 2.0.2 for me. Turning off class caching in development has stopped the error occurring for me, though obviously this is a workaround. I agree with others that this seems to occur on the second accessing of records, It popped up for me on the second time I updated a record.

08/16/08 04:28:45 changed by davidcharboneau

I've seen this as well with Rails 2.1.0 on Ruby 1.8.7 on Mac OS X 10.4. The workaround mentioned worked for me as well.

08/19/08 01:50:23 changed by np1

  • cc set to jason.barnabe@gmail.com.

08/25/08 20:46:57 changed by cgansen@gmail.com

+1, seeing the issue in:

About your application's environment Ruby version 1.8.6 (universal-darwin9.0) RubyGems version 1.2.0 Rails version 2.1.0

Workaround (in original message) does not work for me.

09/03/08 14:31:28 changed by namxam

I am not sure what's wrong with my installation, but I am having the same problem + some more. I am running the Bitnami RubyStack on Windows Vista.

I can fix this bug for Rails 2.1.0 when changing line 244 in attribute_methods.rb to the one mentioned in the original post. This fixes the id problem.

Unfortunately, this does not fix my second problem. In the association where this id problem occured I can only access the attributes / methods created by the activerecord base class, not the ones Ii have added to the user model. Really strange!

09/23/08 19:34:48 changed by nnovik

+1

Ran into the same problem on OSX 10.5.5, Rails 2.1, ruby 1.8.7 (2008-06-20 patchlevel 22) [i486-linux]. The workaround also worked just fine for me, and to clarify since attribute_methods.rb has changed since the OP posted, the workaround goes in method_missing and is just a change of this first line here:

      if self.class.primary_key.to_s == method_name
        id
      elsif md = self.class.match_attribute_method?(method_name)

to this:

      if false and self.class.primary_key.to_s == method_name
        id
      elsif md = self.class.match_attribute_method?(method_name)

10/20/08 15:11:05 changed by ahabman

I have this issue also. Is there anything I can do to help with the resolution? Has anyone found other solutions, or workarounds?

ruby - ruby 1.8.6 (2007-09-24 patchlevel 111) [i486-linux]

rails - 2.1.1, (using globalize plugin)

ubuntu - 8.04

shared issues from previous comments:

1) only occurs when config.cache_classes = false in the config

2) I can load an action without error the first time but if I refresh the page the error occurs on the second and every subsequent view until I restart the server

3) this work around doesn't work - if false and self.class.primary_key.to_s == method_name

10/21/08 18:40:39 changed by mossy

I was having the problem listed above working on an upgrade from rails 1.2.6 to 2.1.1, OSX 10.5.4

Notice on another site a note from their upgrade work The old will_paginate plugin won’t work with Rails 2.1. You get tons of errors like stack level too deep

http://blog.insoshi.com/2008/07/03/a-rails-21-case-study-upgrading-the-insoshi-social-networking-platform/

Remove the old copy of will_paginate

./script/plugin remove will_paginate

Installed the new version

./script/plugin install git://github.com/mislav/will_paginate.git

Now things appear to be working both with and without the workaround applied to attribute_methods.rb

11/09/08 07:06:51 changed by efdi

If you do not want setting config.cache_classes to true (reloading server after every code change is very annoying) you can try something like this:

WAS:

<%= link_to comment.user %>

(link_to tries to generate user_path and runs into infinite stack loop while getting user.id)

FIX:

<%= link_to User.find(comment.user[:id]) %>

You can also wrap this into helper method that will behave depending on the current environment.

01/29/09 04:58:28 changed by np1

Using Rails 2.2.2 and Ruby 1.8.7, this is no longer occurring on my box. Can someone else confirm?

01/29/09 05:09:33 changed by np1

Scratch that, I just forgot that it only occurs on the second request.