Stack level too deep

Hi!    I am getting following error:

SystemStackError in Database#index

Showing layouts/application.rhtml where line #90 raised:

stack level too deep

Interesting thing is that this only occurs when I run the application in development mode. While running in test and production modes, there is no error.

Can any body guide me where the problem might be?

Regards, Mohsin

I know its noisy, but I am placing the stack trace for reference here:

====== STACK TRACE STARTS ========= vendor/rails/activerecord/lib/active_record/attribute_methods.rb: 193:in `method_missing' vendor/rails/activerecord/lib/active_record/attribute_methods.rb: 194:in `method_missing' vendor/rails/activerecord/lib/active_record/associations/ association_proxy.rb:125:in `each' vendor/rails/activerecord/lib/active_record/associations/ association_proxy.rb:125:in `send' vendor/rails/activerecord/lib/active_record/associations/ association_proxy.rb:125:in `method_missing' vendor/rails/activerecord/lib/active_record/associations/ association_collection.rb:162:in `method_missing' vendor/rails/actionpack/lib/action_view/base.rb:637:in `send' vendor/rails/actionpack/lib/action_view/base.rb:637:in `compile_and_render_template' vendor/rails/actionpack/lib/action_view/base.rb:365:in `render_template' vendor/rails/actionpack/lib/action_view/base.rb:316:in `render_file' vendor/rails/actionpack/lib/action_controller/layout.rb:268:in `render_without_benchmark' vendor/rails/actionpack/lib/action_controller/benchmarking.rb:51:in `render' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' vendor/rails/actionpack/lib/action_controller/benchmarking.rb:51:in `render' vendor/rails/actionpack/lib/action_controller/base.rb:1153:in `default_render' vendor/rails/actionpack/lib/action_controller/base.rb:1159:in `perform_action_without_filters' vendor/rails/actionpack/lib/action_controller/filters.rb:697:in `call_filters' vendor/rails/actionpack/lib/action_controller/filters.rb:689:in `perform_action_without_benchmark' vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' vendor/rails/actionpack/lib/action_controller/benchmarking.rb:68:in `perform_action_without_rescue' vendor/rails/actionpack/lib/action_controller/rescue.rb:199:in `perform_action_without_caching' vendor/rails/actionpack/lib/action_controller/caching.rb:678:in `perform_action' vendor/rails/activerecord/lib/active_record/connection_adapters/ abstract/query_cache.rb:33:in `cache' vendor/rails/activerecord/lib/active_record/query_cache.rb:8:in `cache' vendor/rails/actionpack/lib/action_controller/caching.rb:677:in `perform_action' vendor/rails/actionpack/lib/action_controller/base.rb:524:in `send' vendor/rails/actionpack/lib/action_controller/base.rb:524:in `process_without_filters' vendor/rails/actionpack/lib/action_controller/filters.rb:685:in `process_without_session_management_support' vendor/rails/actionpack/lib/action_controller/session_management.rb: 123:in `process' vendor/rails/actionpack/lib/action_controller/base.rb:388:in `process' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:171:in `handle_request' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:115:in `dispatch' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:126:in `dispatch_cgi' vendor/rails/actionpack/lib/action_controller/dispatcher.rb:9:in `dispatch' vendor/rails/railties/lib/webrick_server.rb:112:in `handle_dispatch' vendor/rails/railties/lib/webrick_server.rb:78:in `service' /usr/lib/ruby/1.8/webrick/httpserver.rb:104:in `service' /usr/lib/ruby/1.8/webrick/httpserver.rb:65:in `run' /usr/lib/ruby/1.8/webrick/server.rb:173:in `start_thread' /usr/lib/ruby/1.8/webrick/server.rb:162:in `start' /usr/lib/ruby/1.8/webrick/server.rb:162:in `start_thread' /usr/lib/ruby/1.8/webrick/server.rb:95:in `start' /usr/lib/ruby/1.8/webrick/server.rb:92:in `each' /usr/lib/ruby/1.8/webrick/server.rb:92:in `start' /usr/lib/ruby/1.8/webrick/server.rb:23:in `start' /usr/lib/ruby/1.8/webrick/server.rb:82:in `start' vendor/rails/railties/lib/webrick_server.rb:62:in `dispatch' vendor/rails/railties/lib/commands/servers/webrick.rb:66 /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' vendor/rails/activesupport/lib/active_support/dependencies.rb:496:in `require' vendor/rails/activesupport/lib/active_support/dependencies.rb:342:in `new_constants_in' vendor/rails/activesupport/lib/active_support/dependencies.rb:496:in `require' vendor/rails/railties/lib/commands/server.rb:39 script/server:3:in `require' script/server:3 ====== STACK TRACE ENDS ==========

What’s on line 90 of application.rhtml?

Here are the affected lines:

87: <thead> 88: <tr><th> 89: <!--<%=link_to(image_tag("expand.gif", :size => "9x8", :border =>0), :controller => "javascript(change'')") %>--> 90: <a href="javascript:change('<%=db.id %>')"><img src="/images/< %= (!@db.nil? and (@db.id==db.id)) ? "collapse.gif" : "expand.gif"%>" border="0" id="img<%=db.id %>"></a> 91: <%=link_to_unless_current(t(db.name,{:scope => 'account'}),{ :controller=> "/database", :action =>"list_entities", :id => db.id},{ :title => t("madb_database_menu_link_title")} )%> 92: <span class="menu_action"> 93: <%=link_to(image_tag("icon/small/search.gif", :size => "9x9", :border =>0, :alt => t("madb_search")), { :controller => "/ search", :database_id => db.id}, { :title=> t("madb_search")}) %>

And the perfectly work fine in test and production modes.

Well the issue this: When <%= db.id -%> This causes SystemStackError exception to be raised even in debugger. I mean if I do this in the debugger:

pp db.id Then an exception of SystemStackError is reported. I further traced the problem into rails and in the ActiveRecord::AttributeMethods, (file attive_record/lib/attribute_methods.rb line 194)

# Allows access to the object attributes, which are held in the @attributes hash, as though they 174 # were first-class methods. So a Person class with a name attribute can use Person#name and 175 # Person#name= and never directly use the attributes hash -- except for multiple assigns with 176 # ActiveRecord#attributes=. A Milestone class can also ask Milestone#completed? to test that 177 # the completed attribute is not nil or 0. 178 # 179 # It's also possible to instantiate related objects, so a Client class belonging to the clients 180 # table with a master_id foreign key can instantiate master through Client#master. 181 def method_missing(method_id, *args, &block) 182 method_name = method_id.to_s 183 184 # If we haven't generated any methods yet, generate them, then 185 # see if we've created the method we're looking for. 186 if !self.class.generated_methods? 187 self.class.define_attribute_methods 188 if self.class.generated_methods.include?(method_name) 189 return self.send(method_id, *args, &block) 190 end 191 end 192 193 if self.class.primary_key.to_s == method_name 194 id 195 elsif md = self.class.match_attribute_method?(method_name) 196 attribute_name, method_type = md.pre_match, md.to_s 197 if @attributes.include?(attribute_name) 198 __send__("attribute#{method_type}", attribute_name, *args, &block) 199 else 200 super 201 end 202 elsif @attributes.include?(method_name) 203 read_attribute(method_name) 204 else 205 super 206 end 207 end 208

Look at line number 193 and 194. Because id method is not defined (neither its generated by the generate_attribute_methods) id is called again which gives rise to another invocation of method_missing and which in turn again... So this is an infinite recursions which causes the SystemStackError to occur.

* Now the issue is that why does not this problem occur in test and production environments? * And if its an active record bug, then in what circumstances it occurs? I'm not sure how to simulate this bug except where its occurring now.

Well friends! Problem is over. Its a Rails 2.02 bug and when I discovered it, I also found that its already reported by many others at: http://dev.rubyonrails.org/ticket/10896

    The first ticket describes the situation exactly as it was investigated by us. The workaround mentioned in the ticket did not work for us. The first ticket mentions following reasons for it:

    * When you access models through associations.     * And in development.rb, you have config.cache_classes=false     * While accessing the id attribute for the first time, it does not occur but on each subsequent call, it occurs till the server is restarted.     * Other people also faced this problem on Rails 2.02 with SQLite and MySQL on Mac OS X and Windows

We are on following configurations:    * ruby 1.86    * Rails 2.02    * Ubuntu 7.04    * PostgreSQL 8.2

I can provide the application stack trace also. The ticket at rubydev is updated by me.