Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require Crashes with StackOverflowError and Stack Level Too Deep #375

Closed
ashes999 opened this issue Mar 14, 2013 · 5 comments
Closed

Require Crashes with StackOverflowError and Stack Level Too Deep #375

ashes999 opened this issue Mar 14, 2013 · 5 comments
Assignees
Labels
Milestone

Comments

@ashes999
Copy link

I found an issue that digs deep down to JRuby. Let me start from the beginning; I want to include opengl or gosu into a Ruboto app. So I generate a new ruboto template, and add require 'opengl' or require 'gosu'.

Gosu is easier, since I just drop in the source for Android-Gosu, and don't need to worry about getting the gem working (I opened another issue here about bundling gems).

This results in either StackOverflowError: null or Stack level too deep. The underlying issue is that requiring a bunch of stuff needs a large stack space. Stack Overflow suggests passing in something like -Xms512k to bundle to get around this, which we obviously can't do.

So, this seems like a general bug that phones have very limited stack space, and may cause Ruboto to explode. Here's a simple repro case I distilled:

  • Create a new Ruboto template app
  • Add to the top: requires 'a'
  • Add a.rb: requires 'b'
  • Add b.rb: requires 'c'
  • ...
  • Add i.rb: requires 'j'
  • Add j.rb: puts "You made it!'

On BlueStacks, this explodes fairly quickly. Not sure about on the Android emulator. On my phone (Samsung Galaxy Discover), this explodes on g.rb.

Again, this is not theoretical, but a distillation of my real crash from trying to include android-gosu (lots of require calls) into a Ruboto app. You can read the catlog stack there. It ends with a bunch of these:

 at RUBY.(root)(jar:file:/data/app/org.ruboto.core-1.apk!/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:1)
  at RUBY.(root)(jar:file:/data/app/org.ruboto.core-1.apk!/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:36)
  at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1027)

Please advise.

@rscottm
Copy link
Member

rscottm commented Mar 14, 2013

You'll find that this is a problem that is encountered frequently. You just
need to do the require in a thread that is created with more stack space.
Ruboto facilitates this:

require 'ruboto/util/stack'
with_large_stack{ require 'opengl' }

In this case, your calling thread will wait for the large-stack thread to
finish. You can also just start a separate thread and then have that thread
signal the UI (e.g., stop a progress dialog) when it is done.

On Thu, Mar 14, 2013 at 4:43 AM, Ashiq Alibhai notifications@github.comwrote:

I found an issue that digs deep down to JRuby. Let me start from the
beginning; I want to include opengl or gosu into a Ruboto app. So I
generate a new ruboto template, and add require 'opengl' or require 'gosu'
.

Gosu is easier, since I just drop in the source for Android-Gosu, and
don't need to worry about getting the gem working (I opened another issue
here #373 about bundling gems).

This results in either StackOverflowError: null or Stack level too deep.
The underlying issue is that requiring a bunch of stuff needs a large stack
space. Stack Overflow suggests passing in something like -Xms512k to
bundle to get around this, which we obviously can't do.

So, this seems like a general bug that phones have very limited stack
space, and may cause Ruboto to explode. Here's a simple repro case I
distilled:

  • Create a new Ruboto template app
  • Add to the top: requires 'a'
  • Add a.rb: requires 'b'
  • Add b.rb: requires 'c'
  • ...
  • Add i.rb: requires 'j'
  • Add j.rb: puts "You made it!'

On BlueStacks, this explodes fairly quickly. Not sure about on the Android
emulator. On my phone (Samsung Galaxy Discover), this explodes on g.rb.

Again, this is not theoretical, but a distillation of my real crash from trying
to include android-gosuhttps://github.com/Era-Dorta/gosu-android/issues/1#issuecomment-14895055(lots of
require calls) into a Ruboto app. You can read the catlog stack there. It
ends with a bunch of these:

at RUBY.(root)(jar:file:/data/app/org.ruboto.core-1.apk!/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:1)
at RUBY.(root)(jar:file:/data/app/org.ruboto.core-1.apk!/jruby.home/lib/ruby/shared/rubygems/custom_require.rb:36)
at org.jruby.RubyKernel.require(org/jruby/RubyKernel.java:1027)

Please advise.


Reply to this email directly or view it on GitHubhttps://github.com//issues/375
.

@donv
Copy link
Member

donv commented Mar 14, 2013

On 2013-03-14, at 19:52, Scott Moyer notifications@github.com wrote:

You'll find that this is a problem that is encountered frequently. You just
need to do the require in a thread that is created with more stack space.

Since this has been a very common case, the upcoming Ruboto 0.11.0 release has changed to load the entry scripts in a thread with 128KB stack.

#359

Have any of you had any need for more that 128KB stack when doing a require in an Activity, Service, or BroadcastReceiver?

Uwe Kubosch
http://ruboto.org/

@ashes999
Copy link
Author

I tried wrapping require 'gosu' in a with_large_stack call, but I still see the same error: (SystemStackError) stack level too deep. I also tried building the latest source with the 128KB default for gosu 0.11, but again, the same error (not sure I placed the binary gem in the correct location)

@donv
Copy link
Member

donv commented Mar 15, 2013

try adding an argument to with_large_stack to get even larger stack:

with_large_stack(256) do
  require 'gosu'
end

or

with_large_stack(:size => 256) do
  require 'gosu'
end

@ashes999
Copy link
Author

I retract my comment. It looks like clean wasn't cleaning properly; with_large_stack { require 'gosu' } works.

Thanks!

@ghost ghost assigned rscottm Apr 8, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants