Forum: Rails Engines stack level too deep (SystemStackError)

Ef0db53920b243d6758c2f6b1306df0d?d=identicon&s=25 Steve Ross (cwd)
on 2006-05-01 21:20
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
62b1c7901b1732aef58a91a9fda82753?d=identicon&s=25 Paul Robinson (Guest)
on 2006-05-03 18:58
(Received via mailing list)
On 1 May 2006, at 20:20, Steve Ross 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 Robinson
Ef0db53920b243d6758c2f6b1306df0d?d=identicon&s=25 Steve Ross (cwd)
on 2006-05-03 18:58
(Received via mailing list)
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:in
`underscore'
        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:in
`collect'
        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:in
`const_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:in
`depend_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:in
`run'
        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
62b1c7901b1732aef58a91a9fda82753?d=identicon&s=25 Paul Robinson (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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 Robinson
Ef0db53920b243d6758c2f6b1306df0d?d=identicon&s=25 Steve Ross (cwd)
on 2006-05-03 18:58
(Received via mailing list)
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
62b1c7901b1732aef58a91a9fda82753?d=identicon&s=25 Paul Robinson (Guest)
on 2006-05-03 18:58
(Received via mailing list)
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! :-)

--
Paul Robinson
62b1c7901b1732aef58a91a9fda82753?d=identicon&s=25 Paul Robinson (Guest)
on 2006-05-03 21:26
(Received via mailing list)
On 2 May 2006, at 00:40, Paul Robinson 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 Robinson
Vagueware Ltd - http://vagueware.com
Ef0db53920b243d6758c2f6b1306df0d?d=identicon&s=25 Steve Ross (cwd)
on 2006-05-04 05:13
(Received via mailing list)
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
:(

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.
62b1c7901b1732aef58a91a9fda82753?d=identicon&s=25 Paul Robinson (Guest)
on 2006-05-04 11:50
(Received via mailing list)
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
> :(

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! :-(

--
Paul Robinson
C56e01043a8bc782d00a50ddc1de8ba7?d=identicon&s=25 Chris G. (k-risma)
on 2009-04-15 20:46
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?
This topic is locked and can not be replied to.