Stack level too deep (SystemStackError)

I have the following installed:

Engines version 1.1.1
login_engine 1.0.1
user_engine (no version noted, cuz no CHANGELOG provided, but just
upgraded)

Runs great on my dev machine (don’t they always?) using Ruby 1.8.4,
MacPPC. Rails is installed as edge, version 4306.

I did a clean build-out to the Linux server and of course the dreaded
stack overflow.

Is this still an Engines issue or is there someplace else I should look?

Thanks

On 1 May 2006, at 20:20, Steve R. wrote:

Is this still an Engines issue or is there someplace else I should
look?

If you post a copy of the error, we might have a better idea of why
it failed on your machine, along with a check that you’re pulling the
right versions out in your app on the production machine - you are
using svn:externals, right? Always makes things behave better in my
experience.


Paul R.

On 1 May 2006, at 21:19, s.ross wrote:

Yes, i’m using svn:externals. Because everything is in the vendor
directory, I don’t think I’m getting stale code from anyplace.

Here’s the whole error:

lighttpd -f /tmp/amuinsurance.com_lighttpd.conf -D
/home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/…/
config/…/vendor/rails/activerecord/lib/…/…/activesupport/lib/
active_support/inflector.rb:125:in
`underscore’: stack level too deep (SystemStackError)

Last time I saw that, rails on the production box wasn’t the same
version as rails on the development box. I’d check those, and you can
use svn:externals to shove a copy of rails in vendor/railties if you
need to.

Hope that helps!


Paul R.

Yes, i’m using svn:externals. Because everything is in the vendor
directory, I don’t think I’m getting stale code from anyplace.

Here’s the whole error:

lighttpd -f /tmp/amuinsurance.com_lighttpd.conf -D
/home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/…/config/…/vendor/rails/activerecord/lib/…/…/activesupport/lib/active_support/inflector.rb:125:in
underscore': stack level too deep (SystemStackError) from /home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/core_ext/string/inflections.rb:29:inunderscore’
from
/home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/…/config/…/vendor/rails/activerecord/lib/…/…/activesupport/lib/active_support/core_ext/module/loading.rb:9:in
as_load_path' from /home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/core_ext/module/loading.rb:8:incollect’
from
/home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/…/config/…/vendor/rails/activerecord/lib/…/…/activesupport/lib/active_support/core_ext/module/loading.rb:8:in
as_load_path' from /home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:96:inconst_missing’
from
/home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/…/config/…/vendor/plugins/engines/lib/engines/dependencies_extensions.rb:11:in
require_or_load' from /home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/../config/../vendor/rails/activerecord/lib/../../activesupport/lib/active_support/dependencies.rb:30:independ_on’
from
/home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/…/config/…/vendor/rails/activerecord/lib/…/…/activesupport/lib/active_support/dependencies.rb:85:in
require_dependency' ... 2869 levels... from /home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/../config/../vendor/rails/railties/lib/initializer.rb:42:inrun’
from
/home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/…/config/environment.rb:10
from
/home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/dispatch.fcgi:21:in
`require’
from
/home/vu2045/amuinsurance.com/rails/amuinsurance_com/public/dispatch.fcgi:21

As I said, everything, and I mean everything including Rails is in
the vendor directory. I am certain I am not running an out-of-date
Rails install. The only differences I know of are:

  1. The server is running Ruby 1.8.2 and I am running 1.8.4
  2. The server is Linux i386 and I’m running Darwin 10.3.4

I can factor out (2) because I’ve deployed three sites from this dev
machine to this exact server config with no problems. Any further
thoughts?

Thanks

On 2 May 2006, at 00:40, Paul R. wrote:

If none of those work, if you want to throw me a tarball I can try
things here and see how they fly?

I couldn’t get it to repeat here at this end, however the only thing
that changes between your development and production environments, is
the RAILS_ENV obviously.

I notice a couple of things:

  1. The code that is blowing up is trying to deal with underscores in
    something
  2. Your production database username has an underscore in it.

That’s the only thing I can think of, and that makes absolutely no
sense whatsoever, because it shouldn’t be trying to go near that.

I’m at a loss on this one, but if I get another 15 minutes tomorrow,
I’ll see if I can dig deeper.


Paul R.
Vagueware Ltd - http://vagueware.com

I just changed my local database to have the exact same login
credentials and the problem is not reproducible on the dev machine.
Sorry to bore everyone with this protracted thread. Paul, thanks for
looking this over… for the time being, I’m going to use the Recipes
auth code in a separate branch and revisit this for the next version
:frowning:

BTW: I have like 3 other sites happily running the login and user
engines on configs identical to this. If anyone runs across a possible
reason for the stack overflow, I’d sure be curious to know.

Thanks again.

On 1 May 2006, at 23:42, s.ross wrote:

  1. The server is running Ruby 1.8.2 and I am running 1.8.4

OK, I’ve googled, searched, scratched my head, looked at source, and
here’s my quick-fix guide:

  1. Make sure, and I mean really, really make sure that you’re up to
    date with rails, engines, etc., etc. and they’re all there in vendor/
    plugins

  2. You’ve made the files that need to be chmod +x on the server chmod
    +x after the FTP, yeah?

  3. Make sure the shebang line has the right path for ruby in public/
    dispatch.* and going to work on your production server

  4. Make sure you don’t have anything in your public dir that is a
    backup file, for example dispatch.fcgi~ because you edited it

  5. Try ‘ruby script/server’ and see if that boots OK (shouldn’t need
    this if step 2 is OK)

If none of those work, if you want to throw me a tarball I can try
things here and see how they fly? If it’s commercially sensitive, the
only thing I can think of is if we end up Skypeing and me talking you
through files line by line! :slight_smile:


Paul R.

On 4 May 2006, at 04:10, s.ross wrote:

I just changed my local database to have the exact same login
credentials and the problem is not reproducible on the dev machine.

And I can’t for the life of me get it here.

It’s the point it’s blowing up that confuses the heck out of me…

Sorry to bore everyone with this protracted thread. Paul, thanks for
looking this over… for the time being, I’m going to use the Recipes
auth code in a separate branch and revisit this for the next version
:frowning:

No worries. I’ll take another go at trying to get it to blow up when
I have some free time in a day or two.

Sorry we didn’t get there this time! :frowning:


Paul R.

I have got a similiar problem after trying to execute a
ActiveRecord-Method (update_attributes) in a thread, I get a
stack-lvl-too-deep-error:

@t = Thread.new do
begin
Java::checkout.Files.main main_args.to_java :String

critical code line

@version.update_attribute(:status_checkout, 2)
rescue StandardError => e
puts "[svnkit] "+e
@version.update_attribute(:exception_checkout, e)
end
end

@t.run

Can anyone help me please?