Strange ColdFusion JRUN Stack Overflow Error
This morning, I was doing some local ColdFusion development as I am normally; and, everything was working fine until I suddenly started getting this ColdFusion JRUN error:
java.lang.StackOverflowError at coldfusion.compiler.ExprAssembler.assembleExpr(ExprAssembler.java:144) at coldfusion.compiler.ExprAssembler.cast(ExprAssembler.java:1108) at coldfusion.compiler.StmtAssembler.cast(StmtAssembler.java:362) at coldfusion.compiler.ExprAssembler.assembleExpr(ExprAssembler.java:163) at coldfusion.compiler.ExprAssembler.assembleExpr(ExprAssembler.java:321) at coldfusion.compiler.ExprAssembler.cast(ExprAssembler.java:1108) at coldfusion.compiler.StmtAssembler.cast(StmtAssembler.java:362) at
.... etc.
I was in the middle of making a few updates across various files so, I just assumed that I must have changed something that created a weird memory leak. After commenting out a whole lot of code, I finally narrowed down the cause of the problem to an enormous, compound CFIF statement. This particular CFIF statement had well over 200 conditionals (don't ask), so I could maybe see that it was taking a bunch of memory; but, not only did I not believe that it was killing all of the RAM, it wasn't even part of the code that I was updating.
Starting to suspect that my code was not the culprit at all, I took a look at the Activity Monitor. There, I found out that JRUN was only using about 120MB or RAM. That might sound like a lot, but this sexy beast typically muscles ahead at close to 600MB of RAM. For one reason or another this computer decided to knock JRUN's legs out from under it?
Anyway, I restarted the JRUN server and the RAM went back up to about 570MB. The random stack overflow error was gone. I have no idea what caused it; but, I'm throwing it out there in case anyone else runs into the same thing.
Reader Comments
Looks like during the CFML compilation process that the compiler exceeded the stack space (an area of memory - remember the JVM isn't all about heap memory). Looks like this was the Java stack size (vs native stack size) otherwise you would have seen a HotSpot dump file & error.
You can increase the Java stack size with JVM arguments if you think you need to with "-Xoss" and the native stack size with "-Xss".
Typically your stack size will be just a few hundred KB so activity monitor/task-manager/coldfusion-monitor isnt' going to give you any help here.
There's a ton of non-heap spaces to look out for in the JVM. Between you, I (and your blog readers!) FusionReactor v4 will very likely be helping in these areas - ssshhh, it's a secret!!
@David,
I understood some of what you said there. The JVM is still a bit of mystery to me; although, I am slowly learning some of it. Installing CF as multi-instance mode has definitely helped me wrap my head a bit around the concept of the JRUN server and how things hook into it.
As far as what shows up in the Task Manager, it's usually super consistent regardless of whether or not I am using CF at the time or if I just booted it up.
All,
Somewhat off topic, but not too far. I had some code that ended up spiking the proc and balooning the memory. In my case, a query was looking for its children, but I had made a small change that basically said, "Who are 'god's' children?" and then asked again and again the same question.
Needless to say, JRUN started chomping and wouldn't stop. It grabbed all of the data below the top parent then thought the child of the top parent also had a parent -- "God" had a parent (according to my code).
Took a long while to figure that one out because JRUN would run fine for minutes at a time! But, all the sudden, "Chomp, chomp, chomp." What happened is a user would run that particular query, and set off the chain reaction. I finally figured it out by opening Task Man and trying one thing -- waiting. Trying another, then waiting. I tried the query I thought was the problem, and sure enough it started spiking the processor.
@Randall,
Yeah, there has got to be something that is causing a bottle neck in a random way. I say this because the pages that are timing out are ones that don't have a lot of processing. Most of the pages that get viewed on this site are Blog Entry pages; and, most of the data on these pages is getting cached. As such, there's got to be something that's causing a bottle-neck somewhere that is locking out page processing for a good period of time.
This weekend, I'll really scour my Application.cfc; I think I might be doing a lot of stuff in my onRequestStart() event handler.
Hi Ben,
I'm curious to know if you've used FusionReactor on this server? I think it will help you a lot in tracking down your issues - especially if you've got pages timing out.
(Yes I'm biased and work for Intergral - the company behind FR)
Thanks,
D
@David,
There's no particular reason I haven't used it yet; I think it's just one of those "server" things that I never felt all that confident with. When I got into programming, there was always someone at my companies who just handled that stuff for me. It is an emotional barrier that I simply have to overcome.
My problem is slightly related, but thought I'd post in case someone else had the same problem I did. I was writing a custom tag I had named FirstData, whenever I would run it, it would cause a stackoverflowerror. Once I renamed the tag it worked fine, so I'm assuming First or Data were reserved words.
Hi Ben,
When i login my application it throws the following error:
java.lang.StackOverflowError at coldfusion.runtime.NeoJspWriter.enablecfoutputonly(NeoJspWriter.java:372)
We are using Coldbox framework. Could you help me
thanks
B.Srinivasan
Hello Srinivasan,
A common cause for that error is if you're doing recursion and your "exit condition" isn't being met. Think of the stack as the area of memory listing all the functions/points-of-code that you're jumping between. If you jump between lots of functions/points-of-code then you're going to have a large stack for the request. Typically the default stack size is just fine - I've not come across a valid reason to change it yet - and you'll want to adjust your code as you're probably doing something very inefficient.
Having said that, if you really think you need to adjust the stack size then "-Xoss" or "-Xss" are the JVM arguments you need to look at.
If Ben doesn't mind me plugging our own services then I'd point you at our CFconsultant brand where we'd be able to help you in a consulting engagement if you're looking for help resolving this.
Best regards,
David Stockton
Full disclosure: I work for Intergral, makers of FusionReactor and providers of CF consulting through the CFConsultant brand.
Hey,
Recently I updated my jrun4 using the latest updater 7 and now i am having memory issues :(:(:( any help is appreciated