5
votes

This is a question about what debugging strategy I should use when encountering a stack level too deep (SystemStackError) using Ruby and Rails.

I am seeing these errors when using either rspec or cucumber

perrys-MacBook-Pro:pc perry_mac$ cucumber
stack level too deep (SystemStackError)
/Users/perry_mac/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:240  

perrys-MacBook-Pro:pc perry_mac$ rspec
/Users/perry_mac/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:240: stack level too deep (SystemStackError)
perrys-MacBook-Pro:pc perry_mac$ 

I suspect the problem I have introduced here is independent of both rspec and cucumber. I'm not sure how to narrow down the problem. What should I try next?

I have already tried bundle update, which ran fine.

The app runs fine under rails s , but I'd like to make use of the rspec and cucumber tests I've written.

ADDENDUM:

I see this with the simplest of tests, for instance:

perrys-MacBook-Pro:pc perry_mac$ cat ./spec/controllers/page_controller_spec.rb
require 'spec_helper'

describe PageController do

end
perrys-MacBook-Pro:pc perry_mac$ rspec ./spec/controllers/page_controller_spec.rb
/Users/perry_mac/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:240: stack level too deep (SystemStackError)
perrys-MacBook-Pro:pc perry_mac$ 

ADDENDUM 2: pastebin of spec_helper is here: http://pastebin.com/ePdGyHQh

ADDENDUM 3: pastebin of Gemfile is here: http://pastebin.com/xkLYGjsY

ADDENDUM 4: I have determined that this is the line in spec_helper.rb that leads to the error

require File.expand_path("../../config/environment", __FILE__)

If I put a deliberate syntax error right before that line, I get a 'syntax error' If I put the same syntax error after the line, I get the 'stack too deep error.'

Seems like some progress. Should require File.expand_path("../../config/environment", __FILE__) be written some other way?

ADDENDUM 5: I added this to spec_helper.rb:

puts File.path("../../config/environment") 
puts __FILE__
require File.expand_path("../../config/environment", __FILE__)

and now see this:

perrys-MacBook-Pro:pc perry_mac$ rspec ./spec/controllers/page_controller_spec.rb
../../config/environment
/Users/perry_mac/rails_projects/pc/spec/spec_helper.rb
/Users/perry_mac/.rvm/gems/ruby-1.9.3-p327/gems/activesupport-3.2.13/lib/active_support/dependencies.rb:240: stack level too deep (SystemStackError)
perrys-MacBook-Pro:pc perry_mac$ 

... but am not sure what the implications are based on the output.

ADDENDUM 6:
Using pry, I stepped through the code. A pastebin of the output just before failure is here: http://pastebin.com/c6ZfPmVn Is this helpful or should I include something else? Looks like execution continues up until this point:

/Users/perry_mac/.rvm/gems/ruby-1.9.3-p327/gems/rspec-core-2.13.1/lib/rspec/core.rb @ line 69 RSpec.reset

ADDENDUM 7: I just confirmed I can checkout an older git branch that has working rspec and cucumber. Could having a working branch help me debug the more recent broken branch in any way?

Addendum 8: According to the Pry execution trace, the error happens immediately after a call to Rspec.reset

4
removed spork from Gemfile and spec_helper.rb. Still getting stack level too deep error. - Perry Horwich
I have addended my question to show the line that is leading to the error. - Perry Horwich
No, that's how it should be written. Do you have something in that file that is trying to do recursive things? - sevenseacat
Not intentionally. Certainly not knowingly. - Perry Horwich
updated my question to include some runtime info - Perry Horwich

4 Answers

1
votes

I found the cause using

git bisect

and

git show [commitID]

I was able to go back through my log of commits and find a working version. Then, using the instructions for git bisect here, I was able to find the commit that introduced the stack too deep error. I then used git show [commitID] to see two potential lines of code that were to blame. They were:

# file:app/controllers/thisControllerFileIhave.rb

require 'dicom'
include DICOM

making this change seems to have fixed the problem:

require 'dicom'
#include DICOM

Quite honestly, I do not recall why I added 'include DICOM' (commit was in Oct,2012) nor do I understand why or how this would cause both rspec and cucumber to fail so spectacularly and cryptically. Nor do I understand how running the app under rails s works fine with this code, but the test suite does not. I would thank the poster who suggested git bisect, but their comment seems to have been removed.

Most of the answers and comments I got for this question did not directly address a debugging strategy as much as they offered first hand accounts of when the authors had seen and corrected an error like this. I am grateful to have come across git bisect and git show and I feel they are really powerful options for pinpointing the source of problems like this one.

0
votes

Stack level too deep error points usually to infinite recursion call. Try narrowing your test suit step by step. Can you run rspec and cucumber with just dummy tests? If yes than find which test is causing the error, if not, than check your test enviroment settings, rspec and cucumber settings and initialization files.

Also this error can be often caused by wrong includes / requires. Take a look at what you are including into your tests.

0
votes

My best bet is one of your files in confign/environment is requiring the spec helper itself.

Lets say file A has this line

require File.expand_path("../../config/environment", __FILE__)

and file B says

require 'A.rb'

that would introduce the infinite loop/stack error I believe.

0
votes

Check on your rails app for load methods. I think you have multiple load methods that try to load the same file multiple times.