Reference Citations - HerongYang.com - v2.95, by Herong Yang
org.jruby.exceptions.RaiseException: stack level too deep
'-Xss JVM Option for Stack Size' tutorial was cited in a puppetlabs.com support ticket in 2015.
The -Xss JVM Option for Stack Size tutorial was cited in a puppetlabs.com support ticket in 2015.
Subject: [PUP-4775] org.jruby.exceptions.RaiseException: (SystemStackError) stack level too deep Date: June 4, 2015 Author: Christopher Price Source: https://tickets.puppetlabs.com/si/jira.issueviews:issue-html /PUP-4775/PUP-4775.html >Summary > >Serialization/Deseerialization of Puppet::Node objects using yaml >causes the entire environment associated with the node to be >serialized in full - this is everything loaded and evaluated in the >environment, and it goes very deep. As noted in comments, it is >possible to work around the issue of hitting a stack overflow by >increasing the stack and making more memory available. > >The root cause is that objects (such as Puppet::Node) which requires >asymmetric serialization (it only wants a serialization of the >environment's name, and looks up the environment on deserialization) >must include a module: >... Oh, good point, it may be getting called during serialization indeed. It could be a cyclic reference. If that's the case it may be hard to track down w/o getting a stack line that is outside of the psych library. Not sure how to do that w/o instrumenting psych... it should be possible to hit a breakpoint in psych if we got a ruby debugger attached, a la: https://github.com/puppetlabs/puppet-server/blob /master/documentation/dev_debugging.markdown#ruby-debug , but that would require adding a line to the Puppet ruby code to trigger the debugger. I can help you with that if you're interested in giving it a try. Another thing that might be helpful is to narrow down which kind of HTTP request is triggering the issue. My guess is that it might be a 'report' request, because that's one of the only places where we still serialize things to yaml that I can think of off of the top of my head. So, you could try disabling reports temporarily (see https://docs.puppetlabs.com/references/latest/report.html ). Or, you could watch the puppetserver-access.log file and see what the last request that it logs is, matching up with the error that you see in the puppetserver.log file. It's possible (though not necessarily likely) that there's just a big enough object we're writing that it actually needs more stack depth than what the JVM is capping it at... in which case, increasing the JVM stack size might fix it. To do this you'd set the "-Xss" setting in your /etc/defaults/puppetserver or /etc/sysconfig/puppetserver. The default is, I believe, something like 256KB. You could try setting it to 1M or 2M, a la https://www.herongyang.com/JVM/Stack-Overflow-Xss- JVM-Option-for-Stack-Size.html , and see if that helps us find the culprit.
Table of Contents
SSL/TLS Overview - Change Cipher Spec Protocol
PFX to Java Keystore / Extract private key from Java Keystore
Android talks #08 decompiling android applications
Cpronto 2.5 Administration Guide
IMPLEMENTATION OF SECURE HASH ALGORITHM SHA-1 BY LABVIEW
Cryptographic Protocols - The Peruvian Coin Flip
Bug 378637 - Add support for connecting to HTTP proxy over HTTPS
an information literacy technology for chemistry documents
►org.jruby.exceptions.RaiseException: stack level too deep
Another function that helps programmers calculate
CONNECTING TO A SOAP WEB SERVICE
Application of the Enhanced SHA-1
Apex Soap call authentication problem
Recording Video of an Android Device
Java HTTPS server code failing
How to Capture Logcat Files Using ADB