Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

stack level too deep #97

Closed
mbajur opened this Issue · 13 comments

5 participants

@mbajur

Hello,
i was trying to integrate picky with my rails application (3.2.8) using the tips from Picky's documentation and everything seems to work great except one thing.

I've created an action (/search) which transform picky response id's to entry titles queried from the database and returns the result in json format.

This one single action works but when i'm enabling picky gem in my Gemfile, every single action (instead this one mentioned above) returns an exception:

stack level too deep

The stacktrace:

actionpack (3.2.8) lib/action_dispatch/middleware/reloader.rb:70

It's not the fault of my code (files i've edited when following the documentation) cause even if i'll remove this code, the error is still there. The only option to make app work again is to remove picky from gemfile.

Thanks in advance for any help.

@ghost

Try on production env or set config.cache_classes = true may help :D

@duyleekun

Perhaps you implement the getter inaccurately

THE FOLLOWING CODE IS NOT CORRECT

attr_accessible :attribute_name

def attribute_name
  self.attribute_name
end
@mbajur

Unfortunately none of those solution worked. And it's not a getter fault cause i don't need to have any picky-releated code in my app, it is enough if i add gem 'picky' in Gemfile to cause the error.


Edit: Ok i solved this out, it was connected to gem order in Gemfile so i moved gem 'picky' line right below gem 'rails' line.

@mbajur mbajur closed this
@floere
Owner

Have you found the reason for the problem?

@mbajur

yes, the answer is in my previous comment ;) i dont'really get it why it works right now...but it works.

@floere
Owner

That's not really the underlying reason – just a lucky guess :) Glad to hear it works though…

@andi

I had a similar problem where multi_json generated a "stack level too deep" error upon Index.dump and Index.load. I'm using it inside a Rails 3.2.11 app, with no special json gem installed, so multi_json used json_gem as an adapter.

I solved the issue installing the oj adapter. However, I didn't look into the root cause of the problem.

@floere
Owner

Thanks for the feedback, Andy – sadly my time atm is very limited, and I can't look into it in more detail (not that you ask for it).

@inukshuk

This is baffling to say the least. I just spent about 6 hours debugging a Rails app: after hunting around in the sprockets and actionpack sources I finally figured out that I could reproduce the issue with a pristine Rails app and my Gemfile only. So I went through the Gemfile line by line – removing picky or globalize3 was the only thing that helped. Moving picky in front of globalize3 also solved the problem; but this is definitely something that we should look into.

For the record, my problems were limited to asset compilation. Something that picky does at load time seems to correlate with something globalize3 does in a bad way.

This is the absolute minimal setup I found to reproduce this (Rails 3.2.11):

$ rails new issue97
$ cd issue97
$ echo "gem 'globalize3'" >> Gemfile
$ bundle install
$ bundle exec rake assets:precompile # -> works
$ echo "gem 'picky'" >> Gemfile
$ bundle install
$ bundle exec rake assets:precompile # -> stack level too deep!

After switching picky and and globalize3 it works. AFAIK the order in the Gemfile cannot lead to different versions of gems being installed (in this case the lock files are identical) but it will influence the order in which bundler requires the Gems.

Need to run now. I hope this helps for now. I'll gladly help if there's anything I can do!

@floere
Owner

Thanks @inukshuk.

I cannot reproduce it when only using globalize and picky.

Gemfile

gem 'picky'
gem 'globalize3'

Then, running these pieces of code (with bundle exec):

require 'picky'
require 'globalize3'

MultiJson.dump 'json'
require 'globalize3'
require 'picky'

MultiJson.dump 'json'

Works fine. So it's not the interaction of only picky and globalize, but picky, globalize, and rails (which I assume, is what you were implying).

Jumping off your example, I'll look into the problem what happens when combined with Rails – thanks again!

@floere
Owner

It is baffling indeed. I am wondering how globalize3 and Picky interact. Globalize only depends on multi_json via activerecord and activesupport, but does not use MultiJson directly in its code.

Picky does, however. On load time, Picky runs this code:

MultiJson.use :yajl if defined? ::Yajl

So if Yajl exists, Picky tells MultiJson to use that one (if you set it differently in your Rails app, that will be used instead, as that code will be run later on).

I think a good idea would be to find out where exactly we get the "stack level too deep"…

stack level too deep
  (in /Users/hanke/temp/issue97-2/app/assets/javascripts/application.js)
@floere floere reopened this
@inukshuk

@floere sorry for the late reply (the issue lost some of its immediate importance once I figured out it worked with a different load order). I did spend some time in the debugger and, if I remember, the 'stack level too deep' occurs in the asset pipeline – interestingly only in the production environment (the assets:precompile task also switches to production automatically) – the main difference to other environments is that sprockets uses a different environment class (Index iirc?) in production (for improved caching I believe). To trace the stack level too deep is painful because you're bouncing back and forth between a handful of methods so breakpoints are only of limited use there. Do you have any suggestions how to approach this problem?

Anyway, my apologies that this is all a bit vague (it's been a month after all), but seeing as you you re-opened the issue I thought I'd get back to you.

@floere
Owner

Hi @inukshuk! Thanks for the long entry – I have a report from one user https://groups.google.com/d/msg/picky-ruby/yiEAqi_pnGY/uL60n-v_cicJ that this error does not occur anymore in 4.13.1.

@floere floere closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.