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.

Sign up for GitHub

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

Jump to bottom

Infinite recursion in ActionDispatch::Request::Session.inspect #3793

Closed
hydrogen18 opened this issue Apr 11, 2016 · 6 comments
Closed

Infinite recursion in ActionDispatch::Request::Session.inspect #3793

hydrogen18 opened this issue Apr 11, 2016 · 6 comments
Labels
java integration JRuby 1.7.x JRuby 9000 needs tests Rails regression
Milestone
Non-Release

Comments

@hydrogen18
Copy link

I am seeing infinite recursion in the java stack that is just ActionDispatch::Request::Session#inspect calling itself forever. The implementation of this calls super but the class does not explicitly inherit from any class.

This was not reproducible on a Mac OSX machine with JRuby 1.7.22

Example script

require 'action_pack'
require 'action_dispatch'
puts ActionPack.gem_version
session = ActionDispatch::Request::Session.new({},{})
session.instance_variable_set(:@loaded, true)
puts session.inspect

Environment

[ericu-destroyer-of-worlds] community$ uname -a
Linux ericu-destroyer-of-worlds 3.13.0-74-generic #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[ericu-destroyer-of-worlds] community$ echo $JRUBY_OPTS
--1.9 -J-Xbatch -J-Xmaxjitcodesize128m -J-XX:MaxPermSize=256m -J-Xms1g -J-Xmx3g -Xcompile.mode=JIT -Xcompile.invokedynamic=false -Xjit.threshold=10000 -Xjit.max=65535 -Xjit.background=false -Xcompile.fastest=true -Xffi.compile.threshold=10000 -Xthread.pool.enabled=true -Xreify.classes=true -Xreify.variables=true
[ericu-destroyer-of-worlds] community$ java -version
java version "1.7.0_75"
Java(TM) SE Runtime Environment (build 1.7.0_75-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.75-b04, mixed mode)
[ericu-destroyer-of-worlds] community$ jruby -v
jruby 1.7.22 (1.9.3p551) 2015-08-20 c28f492 on Java HotSpot(TM) 64-Bit Server VM 1.7.0_75-b13 +jit [linux-amd64]

Expected Behavior

JRuby should behave just like Ruby 1.9.3 when running my example script

From Ruby 1.9.3

[ericu-destroyer-of-worlds] actionpack-4.1.14.2$ ruby ~/actiondispatch_request_session_infinite_recursion.rb 
4.1.14.2
#<ActionDispatch::Request::Session:0x0000000220f628 @by={}, @env={}, @delegate={}, @loaded=true, @exists=nil>

Actual Behavior

Infinite recursion is seen in the java stack

From JRuby 1.7.22

[ericu-destroyer-of-worlds] community$ bundle exec ruby ~/actiondispatch_request_session_infinite_recursion.rb 
4.1.14.2
Error: Your application used more stack memory than the safety cap of 2048K.
Specify -J-Xss####k to increase it (#### = cap size in KB).
Specify -w for full StackOverflowError stack trace
@hydrogen18
Copy link
Author

Also present on JRuby 1.7.24

[ericu-destroyer-of-worlds] ~$ ruby ~/actiondispatch_request_session_infinite_recursion.rb 
4.1.14.2
Error: Your application used more stack memory than the safety cap of 2048K.
Specify -J-Xss####k to increase it (#### = cap size in KB).
Specify -w for full StackOverflowError stack trace
[ericu-destroyer-of-worlds] ~$ ruby --version
jruby 1.7.24 (1.9.3p551) 2016-01-20 bd68d85 on Java HotSpot(TM) 64-Bit Server VM 1.7.0_75-b13 +jit [linux-amd64]

@kares
Copy link
Member

kares commented May 27, 2016

interestingly I am not able to reproduce on Ubuntu ... tried Java 7 as well as 8 with 1.7.24 :

Fetching: i18n-0.7.0.gem (100%)
Successfully installed i18n-0.7.0
Fetching: minitest-5.9.0.gem (100%)
Successfully installed minitest-5.9.0
Fetching: thread_safe-0.3.5-java.gem (100%)
Successfully installed thread_safe-0.3.5-java
Fetching: tzinfo-1.2.2.gem (100%)
Successfully installed tzinfo-1.2.2
Fetching: activesupport-4.1.14.2.gem (100%)
Successfully installed activesupport-4.1.14.2
Fetching: builder-3.2.2.gem (100%)
Successfully installed builder-3.2.2
Fetching: erubis-2.7.0.gem (100%)
Successfully installed erubis-2.7.0
Fetching: actionview-4.1.14.2.gem (100%)
Successfully installed actionview-4.1.14.2
Fetching: rack-1.5.5.gem (100%)
Successfully installed rack-1.5.5
Fetching: rack-test-0.6.3.gem (100%)
Successfully installed rack-test-0.6.3
Fetching: actionpack-4.1.14.2.gem (100%)
Successfully installed actionpack-4.1.14.2
11 gems installed

kares@sputnik:~/workspace/oss$ ruby -v
jruby 1.7.24 (1.9.3p551) 2016-01-20 bd68d85 on Java HotSpot(TM) 64-Bit Server VM 1.8.0_74-b02 +jit [linux-amd64]
kares@sputnik:~/workspace/oss$ ruby actionpack.rb 
4.1.14.2
#<ActionDispatch::Request::Session:0x480bdb19 @exists=nil, @loaded=true, @env={}, @delegate={}, @by={}>

kares@sputnik:~/workspace/oss$ ruby -v
jruby 1.7.24 (1.9.3p551) 2016-01-20 bd68d85 on Java HotSpot(TM) 64-Bit Server VM 1.7.0_72-b14 +jit [linux-amd64]
kares@sputnik:~/workspace/oss$ ruby actionpack.rb 
4.1.14.2
#<ActionDispatch::Request::Session:0x35627359 @exists=nil, @env={}, @by={}, @delegate={}, @loaded=true>

@hydrogen18
Copy link
Author

@kares did you set your JRUBY_OPTS what I indicated ?

@headius
Copy link
Member

headius commented May 27, 2016

I don't think the two reify flags are a good idea to have on...they were experimental in 1.7 and reify.variables defaulted to true for the first time in 9.1.

It appears that having reify.classes enabled causes this issue. It used to work properly, so we must have broken it somehow...or perhaps it never worked for the particular object structure we're dealign with here.

reify.classes has never been made official, but now might be a good time. It would need to be unified with reify.variables, since both flags attempt to change what actual objects get allocated for a Ruby class. We may or may not do this in 1.7, but I think it's a good time to get class reification stable in 9k.

Short term workaround: remove reify.classes from your JRUBY_OPTS and it should run fine.

@headius headius added this to the JRuby 9.1.3.0 milestone May 27, 2016
@headius headius modified the milestones: JRuby 9.1.4.0, JRuby 9.1.3.0 Aug 15, 2016
@headius
Copy link
Member

headius commented Aug 15, 2016

Reasonable workaround for now and larger work needed to get reify.classes working properly again.

@headius headius modified the milestones: JRuby 9.2.0.0, JRuby 9.1.6.0 Nov 8, 2016
@headius headius mentioned this issue Jan 19, 2017
Closed
@ivoanjo ivoanjo mentioned this issue Jun 2, 2017
Open
@headius
Copy link
Member

headius commented May 15, 2018

Closing in favor of a new task issue. The reify.classes feature is still experimental and unsupported with reify.variables, which has been enabled and working well for some time. I have plans to rework reify.variables to actually generate the specialized class shapes, but that will happen after 9.2. At that point I will look into whether we can actually just do the reify.classes logic as part of the generated subclasses.

@headius headius closed this as completed May 15, 2018
@headius headius modified the milestones: JRuby 9.2.0.0, Non-Release May 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
java integration JRuby 1.7.x JRuby 9000 needs tests Rails regression
Projects
None yet
Milestone
Non-Release
Development

No branches or pull requests
4 participants
@headius @enebo @kares @hydrogen18