To the guys keen to tag it as a duplicate question, please wait and read below:
Before posting this question, I have searched the SO extensively but none of the solution given for the OutOfMemoryError worked for me. I was getting this issue when using the ant build.
The solution that didn't work:
1. export ANT_OPTS=-Xmx1g
ant
2. set ANT_OPTS=-Xmx1g
ant
3. export ANT_OPTS="-Xmx2g -XX:MaxPermSize=512m"
and few others as well
So here is the solution that I found for my problem:
Since the project that was failing and throwing OutOfMemory error has it own build.xml file.
In the build.xml file, there was a property tag that allocates the memory needed for java compiler. That memory was low. After increasing the memory allocation, it resolved my problem.
<property name="javac.max.memory" value="2024M" />
Hope it helps
Related
I currently I have a problem that when I run my code, it stops at an exception at line 3467 in the xstring system file. Here is a few screenshots of it:
.
I figured it had to do something to do with loading the file or the file is corrupted. Something is wrong with how it parses. Here is the link to my Github page. I used the tmxlite parser to load the file, here is also a link to the tmxlite Github page. Thanks so much! Sorry if this is a dumb question. I really have not programmed C++ for long, and done it without proper training. This is the tmx file link
I am so sorry for those who looked at this. It turns out I needed to edit my tmx files to include the tsx files and add the tsx files to the project. I am so sorry if I made anyone look for the answer when all I had to do was just use the resources in front of me. Thanks to underscore_d for telling me make it into a MCVE, leading me to find the answer. All this time... Sorry anyone whose time I wasted.
i am a new Clojure/Cascalog user trying to migrate some pig scripts, but often i get an error like the following in repl.
FlowException local step failed cascading.flow.planner.FlowStepJob.blockOnJob (FlowStepJob.java:191)
"with-debug" gives some more information but still no root cause of the issue. Any ideas on how to improve this?
I agree that the stacktraces are sometimes very unhelpful. One thing I can suggest is writing unit tests: http://sritchie.github.com/2011/09/30/testing-cascalog-with-midje.html which narrows down significantly where your actual problem lies.
If your query works for basic cases but fails on big data you can add a trap, to see what inputs are causing a failure:
(<- .... (:trap (hfs-textline "s3://.../errors" :sinkmode :replace)))
today I ran into an error and have no clue how to fix it.
Error: App with label XYZ could not be found. Are you sure your INSTALLED_APPS setting is correct?
Where XYZ stands for the app-name that I am trying to reset. This error shows up every time I try to reset it (manage.py reset XYZ). Show all the sql code works.
Even manage.py validate shows no error.
I already commented out every single line of code in the models.py that I touched the last three months. (function by function, model by model) And even if there are no models left I get this error.
Here http://code.djangoproject.com/ticket/10706 I found a bugreport about this error. I also applied one the patches to allocate the error, it raises an exception so you have a trace back, but even there is no sign in what of my files the error occurred.
I don't want to paste my code right now, because it is nearly 1000 lines of code in the file I edited the most.
If someone of you had the same error please tell me were I can look for the problem. In that case I can post the important part of the source. Otherwise it would be too much at once.
Thank you for helping!!!
I had a similar problem, but I only had it working after creating an empty models.py file.
I was running Django 1.3
Try to clean up all your build artifacts: build files, temporary files and so on. Also ./manage.py test XYZ will show you stack trace. Later try to run python with -m pdb option and step through the code to see where you fail and why.
You don't specify which server you're using. With Apache you'll almost certainly need a restart for things to take effect. If you're using the development one try restarting that. If this doesn't work you may need to give us some more details.
I'd also check your paths as you may have edited one file but you may be using a different one.
Plus check what's still in your database, as some of your previous versions may be interfering.
Finally as a last resort I'd try a clean install (on another django instance) and see if that goes cleanly, if it does then I'd know that I'd got a conflict, if not then the problem's in the code.
I have a fairly long cfc file, about 1800 lines long, that worked fine in ColdFusion 8, but after upgrading my development system to ColdFusion 9 and doing some testing I get a compile error for a cfc and the message says "Branch target offset too large for short". I modified the file to eliminate some unused functions and consolidated one to make it shorter and this resolved the problem to get it to work. But still, why did it die on me now when I upgraded to CF9? Anyone else run into this problem in previous or the current version of ColdFusion? Are there any solutions other than modifying the cfc file such as upgrading the jvm?
EDIT
If you have an answer to the questions I have, great! Post that, but don't waste time telling me something that I already know. If you are going to post a response, please read the question carefully and answer only if you know the answer. Don't do a google search and post crap that I already know and utilized to get the code to work. The question is, why did it work in CF8 and now not in CF9? Are there other solutions besides what I did?
This is a problem inherent with the JVM as you already know, CF9 has likely added more innate functions to a component and if the methods are all referenced via a giant switch statement with a short being used as the offset, we have less offset pointer space to work with each successive version. People moving from CF7 to CF8 also had the same problems.
So short answer is no.
Most recommendations you find basically tell you to split a large method into a smaller method and several helper methods. The first time I ran into an issue this worked for a large cfc I had. But then as it got bigger no number of helper functions would fix it. Eventually it had to be split into multiple cfcs.
PS: This guy said removing a transaction helped (CF7), there are none wrapping my calls though, so it's not a guaranteed fix I guess http://www.coldfusionmuse.com/index.cfm/2007/9/28/Branch.Target.Offset
Edit
Looks like my previous issue was a different function being too large, splitting the CFC into multiple CFCs was in error. I've since split that problem method into smaller methods, and have been able to consolidate all the functions in one CFC. So that is the solution it seems.
If you haven't already, try running the Code Analyzer in the CFAdmin page, "Debugging & Logging > Code Analyzer". This is a useful tool to find some changes which were made in the language between CF8 and CF9.
We had to change several variable names and function names as CF added them in 9.
Also check here:
http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec22c24-7ff0.html
CF version: 10
OS: Linux CentOS 6.0
Did face a similar issue where I had 1300+ lines of code in my cfc and one fine day I get the "Branch Target offset.." error. I tried
Code Analyser to find any loopholes of legacy- DID NOT FIX
Edited the cfc to trim down any last bit of redundant code or comments - reduced around 20+ lines of code - DID NOT FIX
I split the code into 2 cfc and extended one to the other- DID NOT FIX
I removed any unwanted dump of queries and arrays (part of testing) : THIS WORKED
so I would suggest ensure you don't have any dumps of large data content. Hope this helps.
coldfusion.compiler.FactoredNodeAggregation cannot be cast to coldfusion.compiler.ASTfunctionDefinition
I get the above error when attempting to replace a really, really old legacy custom tag with a new custom tag that has some substantial workflow improvements. I only have one idea on how to debug this: comment out different parts of the code (binary search style) until it will compile, narrowing my search until I find the problem code.
Has anyone else ever seen this error before? Any idea what it could possibly be? Contextually, it sounds like I'm trying to use ... something... as a function that isn't defined as a function. That doesn't ring a bell so I'm going to try the binary search idea.
Update: It's running on CF 8.0.1, and doesn't use any <cfscript> blocks at all. Using the binary search of commenting out, I've narrowed it down to a CFThread that starts a background thread that never re-joins the page (by design).
If I comment out the entire contents of the thread, the error goes away (so the cfthread tag itself doesn't appear to have problems on its own...). If I copy the contents of the thread to its own template, that template will compile fine (so the thread contents doesn't appear to have problems on its own...)... so... in theory it should work? I don't know. This is me with my arms up in the air. (WTF?)
I think I've already disproven this idea by un-commenting a small section without the error coming back, but a CFThread should have access to local custom tags that the template creating the thread would have, right? so if there's foo.cfm, it could be accessed from the page as <cf_foo>, and the thread could do the same?
In the last week I've been in contact with the ColdFusion Engineering team at Adobe about this issue and they confirmed for me that this is a bug in ColdFusion.
Specifically, if the number of lines of code inside the thread tag body was too large, it would cause a compile error. The work-around, which I discovered a day or two before I got my answer, is to use a <cfinclude /> to import your thread contents from another file; or to put the code into a method somewhere and call that method from inside the thread body. (Presumably, a custom tag or other clever methods of encapsulation would also work.)
That explains the part of the whole thing that was driving me absolutely insane: that commenting out various parts of the thread body would sometimes make it compile... and now I know it was because enough of the thread body was commented out.
They report that they have fixed the bug, so I assume it will be fixed in the next cumulative hot-fix (if there is one), and in ColdFusion 9.
Since I can't comment yet, Adam, is it really a bug with CF or with the JVM? There's a similar limit on how many lines of code can be compiled within a CFFUNCTION, but the limit is really in the JVM, not the CF tag.
Oooh, that's one I've not seen before.
Depending on what the custom tag does, rather than commenting out different parts, you could try using cfabort - same technique, but only one line to change rather than uncommenting and re-commenting (which can be fiddly and time-consuming).
Also, are you able to test the custom tag in isolation, with completely simplified arguments/etc?
If you're able to post the code, there might be something odd that jumps out at a fresh pair of eyes?
that error usually comes up when you have a function that is set to remote. kinda funny that your getting it with a custom tag though. are you sure that the custom tag doesn't have any functions in it? can you post the code?
Strange that it is a compilation error. If the code base is not too huge I would make sure all variables in the thread and called udfs are explicitly scoped.
Next I would move as much externally referenced data into the thread arguments scope to isolate the interactions with the page.
Finally if that does not clear it up I would try mangling the names of every variable, function and udf the thread accesses a bit with some test prefix just to make sure that you have not hit a bug where one of your vars or funcs is causing a namespace collision in the jvm in the context of the original page.
Tricky problem.
Have you deleted the compiled class files and saved the original source to a new file just in case something weird occurred during a save?
Have you tried reinstalling CF8.01? Maybe some files got corrupted?