I've hit quite a couple of 'stack level too deep errors' while building a padrino app, which don't help you in any way to debug the problem.
For example, if I change the database adapter and make a typo in it's name, I get the following error:
/home/fbernier/.rvm/gems/ruby-1.9.3-p0@atom/bin/padrino:19: stack level too deep (SystemStackError)
Nothing else. Sometime I was making a couple of changes and hitting this error, so I have to rollback everything one by one to finally find out it was a typo in the database adapter name...
It has also happened in other situations than the database adapter, but I can't remember.
It would be nice to at least have a stack trace, which I can't seem to get.
I'm getting these errors only when running on snow leopard, identical (rmv) setups on Lion and DP Mt.Lion run fine....
this really need to be fixed
Any thoughts @DAddYE probably the reloader I'd imagine?
👍 Had some fun with this issue yesterday...
This is killing me today... is there a blanket rescue statement or something going down?
if you have this problem check if:
Absolutely, and I did get this resolved. Specifically I was deploying to Heroku. Once I switched to the dev/beta postgresql add on and I got exact connection info everything went much smoother.
But the real issue here is something swallowing up an error.
I had the problem on heroku too btw
I had a similar problem as well - It was because I had commented out sqlite3 as a dependency in my gemfile...
/home/me/.rbenv/versions/1.9.3-p194/lib/ruby/gems/1.9.1/gems/padrino-gen-0.10.6/lib/padrino-gen/generators/cli.rb:27: stack level too deep (SystemStackError)
Steps to reproduce:
Am now having this issue in Heroku OMG.... this makes me sad. it makes me very sad :(
Maybe I'll even start investigating (although I've never been on the inside of Padrino!)
Can anyone who has experienced this help me understand why this seems to happen so often with Heroku? And if you fixed it, how? I have a lot of Padrino apps in use deployed outside Heroku and never experienced this. @LouisSayers mentions commenting out a sqlite3 dep, are there any other common culprits you guys are aware of?
I'm guessing this was never fixed? I'm trying to do postgres and following even just the basic blog tutorial and have spent several hours on this. This is a killer bug and yet doesn't seem like it should be that hard to get the error messages out...
You are right, we do want to fix this and I don't think it will be too hard. I will dig into this tomorrow and hopefully fix this on edge.
Thanks, sorry for sounding hissy on this. I had been running Padrino with Mongoid without issue and then realized had to switch to postgres, and so was just extra frustrated that PAdrino wasn't working as smoothly as I'd been spoiled previously on. I'm sure my own mistake is something dumb....just hard to figure out where I made it without a usable trace :)
Yeah, having no visibility into a stack trace can be understandably frustrating. As I said, I do hope to fix this soon.
I've been digging around in the Padrino code but I haven't yet figured out what's catching this stack trace yet.
I can, however, offer consistent repro steps:
Ok, found it.
I'm not sure if this is how you'd like to fix it, but here's a pull request that gives me a reasonable stack trace for my problem with the postgres adapter:
Having this issue on local dev, a few things I noticed:
@jasonseney this sounds like a good opportunity to try the all shiny and new jister! :) Would you mind pushing your project for debugging? If you're ok with that, please do this: gem install jister && jister push --recipe padrino and share the jisted version here :)
gem install jister && jister push --recipe padrino
@dariocravero Thanks for the tip - looks very interesting! Unfortunately I can't make the entire project public, but I'll see if I can setup a new padrino project that replicates the error and has the same "setup".
@DAddYE @dariocravero @ujifgc Does #959 solve this? Should we merge for 0.11?
No. The fix fails some tests.
OK thanks, good to know.
Yeah, I blew it on that and didn't run any tests before shooting #959 at you guys, sorry - it does hopefully point a way towards a real fix though, and it was helpful for me to see where my code was failing by getting back a real stack trace.
@futurechimp, I think it's great to know a way to get more information other than "stack level too deep" when a weird exception happens, so many thanks for the patch :). Anyway, I reckon we'll have to look a bit further into the solution because even though we shouldn't swallow those exceptions, we definitely have to do something in there to prevent that behaviour from happening. I'll close the PR and we will continue the discussion here.
It would help a lot to have an example to debug. Just by chance, would you have any Dave? Thanks again :)
No trouble closing the pull request, obviously it can't be accepted if I don't put the work in to propose a fix that actually passes tests. I'll create an example app that messes up, let's see if we can fix it.
Ok, take a look in https://github.com/futurechimp/padrino-stacktrace-error - for me, that triggers the bug.
Thanks for the example. For me it goes deep with gem 'padrino', '0.10.7'
gem 'padrino', '0.10.7'
$ bundle exec padrino s
/usr/local/rvm/gems/ruby-1.9.3-p194/bin/ruby_noexec_wrapper:14: stack level too deep (SystemStackError)
But prints some reasonable error with edge gem 'padrino', :github => 'padrino/padrino-framework'
gem 'padrino', :github => 'padrino/padrino-framework'
$ bundle exec padrino s
/usr/local/rvm/gems/ruby-1.9.3-p194/gems/bundler-1.2.3/lib/bundler/rubygems_integration.rb:147:in `block in replace_gem': Please install the postgresql adapter: `gem install activerecord-postgresql-adapter` (pg is not part of the bundle. Add it to Gemfile.) (LoadError)
@padrino/core-members anyone knows what might have fixed that?
@futurechimp, thanks a lot for putting that up for us! :)
As @ujifgc, it's fixed in edge, which is amazing. I did some research and found out that it had to do with the reloader. A commit by @dcu fixed it, it was cleaned up a bit on another commit.
Looks like it didn't make it into 0.10.7 by hours because that patch was applied on the 20th of June, same day when the gem was released!..
I'm closing this issue then. Please, reopen it if you find the stack level too deep error again.
Great, thanks for confirming this was fixed.