My editor freezes on me every day, at least once, and sometimes a lot more. Today it's happened 4 times. I never know when it's going to happen, but it seems to happen more often when I'm working on large files with a mix of cfscript, cftags and html syntax. To get back to work, I have to close the eclipse window, sometimes clicking the close box 2 or 3 times, then force quit the eclipse process from the task manager, and then I can restart eclipse.
I'm running Windows 7 (x64), eclipse 3.5.1 build M20090917-0800 (x32) and ColdFusion Builder 18.104.22.1683215
I cannot start without errors that show up in my log, even after I clear it.
I attached my log file.
We have fixed a couple of freeze issues repoerted in Beta3 build.
Looking at the log file you attached, it is not clear what the problem could be. However a few stack traces obtained when CFB is not responding will help us debug the problem. You can get more information about getting stack traces of CFB at http://blogs.adobe.com/cfbuilder/2009/12/reporting_one-off_issues_with .html
One question for you - do you normally open files for editing in CFB from projects in Navigator or from RDS file view?
I open files from the Navigator, but I'm don't know if I'm looking at the RDS File View. How can I tell? When I click on the view menu button in the Navigator frame, I see Select Working Set, Deselect Working Set, Sort, Filter, and Link With Editor. Not sure if that helps.
Just happened again... I attached a dump file created from http://www.adaptj.com/main/download. Not sure if this is exactly what you need because I couldn't figure out what Process ID the eclipse process was running with. So I had the dump program do all of them, but it wasn't really done... seemed to stall out waiting for me to save the file. So this could be an incomplete file.
In the future, how would I figure out what process to dump?
Thanks for posting the stack trace. However stack trace looks normal and not indicating any problem.
Could you post the Eclipse log again? I think the previous one you posted was the partial log. It would help to post the complete log.
And regarding you post earlier about navigator view, yes from your the description it appears that you use Navigator view to open files. RDS File view is on the right side, in the same tab group as Outline view and RDS Data view.
Also it would help us to reproduce and debug the problem if you could describe when this probelm occurs. Any actions you perform that result in freeze consistently? How do you typically use ColdFusion Builder?
I'm also having frequent crashes on Win 7 x64. Tried turning off the syntax checking but hasn't seemed to make much difference. I have tried to get a thread dump but so far the console has crashed at the same time so will have to try alternative methods. There doesn't seem to be any pattern for when it freezes, I'll just be in the middle of typing in some code and it hangs. I'll have to try and pay attention and see if the size of the file I'm working on makes a difference. I open my files through the project navigator only and the associated localhost server is always running.
Hi Redtopia & MaryJo,
Can you both please share your email addresses with us (firstname.lastname@example.org)? We would like to discuss and investigate this issue with you offline. We need more information from you which would help us resolve this.
Adobe ColdFusion Builder Team
Same issue here, in OS X. (Snow Leopard)
It's a particular template. Just an index.cfm, has some references to the ExtJS tag library in the head. I open it from the Navigator, and /every time/ it pegs out my CPU and locks up the IDE.
Currently I'm at 99.6% CPU, 282MB of RAM and 508MB of Virtual Memory utilization. It's literally the ONLY file I open, and I can consistently replicate it. I sampled the process in the Activity Monitor and attached it, though by that time I pasted it and converted it to PDF the process finally subsided. Probably took 10 minutes for the IDE to go back to 'normal'.
I'm also attaching the .cfm file, but there's not much to it.
I downloaded and ran the new installer (using the link you sent me) and I'm getting a message saying that I already have a version of ColdFusion Builder installed and that I have to first run the uninstaller. I'm not sure what uninstaller to run, and I definitely don't want to lose any of my local preference settings. I'm running CF Builder as a plugin. Any advice?
Were you able to install the update that was given to us? I just tried and my entire eclipse environment is now trashed. The first time I tried to install it, I selected the default location to install the ColdFusion Builder Plugins and then selected my eclipse folder, as requested. No luck... the ColdFusion Builder perspective did not load and eclipse didn't recognize any ColdFusion projects that were previously setup. So I reinstalled and selected the eclipse folder for the location to install the ColdFusion Builder plugins, and that didn't work either. After uninstalling the second time, my eclipse environment will no longer run. I get the error: "The Eclipse executable launcher was unable to locate its companion shared library"
So if you haven't installed yet, I recommend backing up your entire eclipse environment (which I didn't do!!! ouch.) before running the installer. It may be different for you if you are using the stand-alone version.
I'm using CFBuilder as a stand-alone and didn't have any problems installing the new version that was sent to me (after uninstalling the old one). Can't say yet if it's that's much more stable than the prior one, I've had one freeze so certainly can't say it's completely resolved. But at least I'm not having all the issues you are!
I have no idea if this will help anyone else out, but I did a few things that /seem/ to be helping me, though time will tell if this persists.
First off, I noticed this post on Stack Overflow, about Eclipse RAM utilization and some recommended VM settings, and made some updates to my config.ini file in the 'configuration' subfolder based on the settings of the top-rated answerer. Additionally, there was a mention of closing some projects being helpful, so I went through the several projects I have open and closed many of them which I don't use very frequently.
Since then, I haven't gone over 512MB of RAM utilization, and haven't noticed any major issues, except on startup.
On startup, there's a good 5 minutes where the IDE is pretty much unusable, while it Builds the workspace and other rigamarole which one would /think/ is unnecessary, considering it 'saved workspace' when I shut down the previous time....but who knows. Being built on Eclipse, there are probably some glitches here that are also shared by Eclipse.
I don't know if this will help anyone, but it seems to be working for me...on OS X. Your mileage may very.
Thanks Shawn, I looked at my memory usage a few times while Eclipse was hung and it looked fine. Plus, I don't think that making adjustments to Eclipse settings is the best solution (duct tape on a leaky pipe). The first 2 betas did not have the same problem (at least for me), so I think this has something to do with bad code being introduced into the 3rd beta.
We have recently fixed one issue where CFB used to stop responding after using for few hours - in this case stack trace looked normal and showed that the main UI thread was waiting for OS messages, but the UI did not respond. There was a resource leak that was causing this issue.
No, the patch is not released publicly yet and no decision is taken yet on when to release it. We have given the new build to few users who had reported this issue and are in the process of confirming if it fixed their issues.
Ok - I will look forward to that... Eclipse just froze on me for the third time this evening.
Started with a bunch of these in the error log "Error occurred during status handling." and then a bunch of these "Unhandled event loop exception."
Does that sound like the same issue you are referring to?
I hadn't used the first two betas at all, so I had no basis for comparison.
Guess there's a bona fide issue here, so I guess I'll just wait for the next patch and hope things are working. Btw, it wasn't just memory settings. The Stack Overflow post mentions a few GC tweaks and a focus on avoiding a hung process during edits as the primary focus, not really RAM utilization, though tweaking those settings is also a part of that post.
My issues also showed up with the 3rd beta (have used all three). The latest build from Ram does seem to be working much better for me, but will reserve judgment until I have a few more heavy days of use under my belt. Crash-free all day today though, so definitely am improvement over having several crashes a day.
I can only confirm that I'm also seeing the problem, on OSX 10.5, and have to kill CFB and restart it. It has, on occasion, locked the entire operating system up, and I could only kill CFB by typing the Force Quit shortcut keys.
It happened twice while I was coding a CFC written in all script style.
The build 270225 that I have definitely seems to have cleared up the freeze issues, at least for me. Much more stable than the initial beta 3.
The one issue I have that still really drives me nuts is the auto-scrolling issue mentioned in the other thread. Trying to select text that is off the right-hand side of the screen in particular is often like trying to catch a butterfly with your bare hands.
Freezes all the time. Like several times an hour. Sometimes for a few seconds, sometimes can only be terminated by Task Manager.
It does not take processor resources or more memory - it just stops responding and stops displaying anything but some menu icons and some scrollbars.
Apparently setting code assist to 0 milliseconds delay kills it.
Especially if you type inside the cfquery tag - (it looks like it connects to the RDS and tries to pick up all available table names from the datasource),
Well maybe it is helpful but why does it take so long, and why does it keep offering the table name even after WHERE clause?
It would be nice if it worked like the query editor in MSSQL2008
Or if you type and leave a tag unclosed, and then decide to type something else on another line - oops! Not allowed.
Like type <cfset myvariable = > or type <cfif and then start typing somewhere else, inside another tag - likely to freeze for at least a couple seconds
Maybe it works fast enough on machines with dual processors and 15k harddrives, but as is, it looks like an IDE for slow-typers
And then this annoying habit on unfolding a folded code block arbitrarily and unexpectedly when you are typing below it - takes the line you type way down where you cant see it. Instead you see the unfolded code block.
I am also having the very same problem Win 7 x64, Beta 3 standalone install, I have not been selected as a prerelease candidate so i am not sure where to get the latest incremental build which supposedly fixes the issue, but its getting to point the i am just using notepad++ / DW, which makes it really hard to evangelize the product. Is there anything that could be done?
I have had sluggish editor issues, where it pauses for 1-3 seconds while I'm typing, and then catches up by displaying blocks of typed characters all at once. Also code coloring has been extremely slow. This seems to particularly happen in large files (>1500 lines).
I was able to fix the issue with the following steps:
1) Delete the project in Navigator. Don't remove the files from disk of course.
2) Archive the .projects and settings.xml files from your project folder to some safe place if you want.
3) Restart CF Builder, then re-create the project.
Voila! For me, anyway. I have been able to restore my settings.xml file afterwards and have CF Builder pick it up with no issues. I haven't tried restoring the .projects file, but I compared the archived version with the new one created by CF Builder and they were identical for me.
I've been able to go for a few days before the sluggishness shows back up, and then I have to repeat the above steps. I've sent email@example.com an email so hopefully they can get to the bottom of this.
Thanks Darren i can atest to that fix for large projects consisting of large CSS and CFC's, performance seems to be attricous in large CSS files. Rebuilding the project does seem to help. Lets hope this will get fixed soon, since its a pretty big show stopper.
I'm having pretty frequent unresponsiveness since I installed CFBuilder as a plugin to my Eclipse installation. I'm hoping maybe someone can help me work this out because otherwise, I'm liking CFBuilder and I'd like to continue to use it. Here's my setup:
Windows: 7 x64
Thank you for any help you can provide.
I haven't yet installed CFB 2... still using CFB 1, which is buggy as hell. But it doesn't crash, so that's good. I just downloaded CFB 2 and was planning to install it and start using it soon. However, I was going to install it as a stand-alone rather than use it as a plugin. Have you considered trying that? I am running CFB 1 as a plugin, and I don't see any advantage of using it that way because I am only working on CF, HTML JS and CSS files. I assume that CFB 2 as a standalone could be more solid, but I don't know for sure.
I would be curious to hear back from you... I am also running Windows 7 x64.
It helps a lot to turn off Syntax Checking from Window --> Preferences --> Coldfusion --> Editor --> Code Assist ---> . I leave 'Display Syntax Errors Only on File Save' On so i get the same benefit, but it does not keep checking the file.
You may also need to turn off the Quick Fix in the syntax checking, I've seen issues with that depending on how you code (I use Coldspring a lot so it's marking tons of lines as invalid).
I find CFB2 far more stable than CFB1. I did need to install it as a plugin as I also use FlashBuilder and I had trouble getting them to use the same workspace when either was installed as standalone with the other as a plugin. With both installed as plugins, seems to work fine.
Does anyone know where the xml information is stored for settings? I've turned off just about everything in my CFB2, restarted, and still everything seems to persist (syntax checking, auto build, refresh content). It's almost like my settings are not being recognized (it's saving what I'm setting, but CFB2 doesn't seem to realize that I've saved them). I'm getting rather frustrated with it freezing on my quad core, 14GB system. It's the only app that runs slowly and constantly freezes. I'll be switching back to DreamWeaver the way this thing is starting to run again
I finally solved my problems on Windows 7 64bit with the Eclipse plugin by forcing Eclipse to use the jvm.dll rather than let it use the javaw.exe executable which it uses by default. My setup was Win7 64bit, Eclipse 64bit, and 64bit JVM. I experienced all the problems you describe, and more, but since making this change CFB runs teriffic and I was able to turn all the crap I had turned off 'for performance reasons' back on.
Just going to paste the blog post I made about it. Note that this is 64bit stack-specific, and that CFB standalone is 32bit, so if you want to try this on the standalone install you'll need to make sure you've got a 32bit JVM (one comes with standalone, but you can install a newer one from www.java.com as well). I haven't tried this with standalone, only the Eclipse plugin, but if you're experiencing similar issues you might get the same benefit by doing the basics of what's outlined below:
For those of you that continue to experience hangs and massive slowdowns running CFB on Windows 7 64bit, the one thing I found that made all the difference in the world is to have Eclipse use the jvm.dll rather than javaw.exe (the default). I’m using the CFB plugin into Eclipse, but I suspect this may also apply to CFB standalone on Win7 64bit as well. No amount of configuration changes, switching between 32 and 64bit JVM/Eclipse or disabling of features made any difference to the significant performance problems I was continuing to experience UNTIL I explicitly had Eclipse start up using the dll (forcing the JVM to load within the Eclipse process).
I also found that simply adding the –vm argument to the eclipse.ini apparently doesn’t work when trying to specify a specific JRE to use (at least on my machine); regardless of the existence of this argument in the ini file, it will still always fire up C:\Windows\System32\javaw.exe, which is where the problems I was seeing are (high CPU utilization, memory consumption). Not sure why that argument is ignored, perhaps a path issue, but I found that the only way I could be certain that I could run Eclipse with a specific JRE was to invoke Eclipse with the –vm command line argument.
I removed all my old JRE installs and installed the most recent 64bit JRE to C:\Java\64bit\.
I first tried updating eclipse.ini with:
but found that Eclipse was still invoking the C:\Windows\System32\javaw.exe for some reason. Eclipse started of course, and the javaw.exe process started going bananas again every time I would try to edit a file and *change the value of an html input tag* of all things – as soon as I changed the input value by adding one letter (even before saving) the javaw.exe process would immediately start eating cpu and memory, and I could repeat this problem consistently across multiple files. Eclipse would hang, and I’d have to forcibly kill it as it would never recover.
I then tried invoking Eclipse with the command line –vm argument, like so:
D:\eclipse\eclipse.exe -vm C:\Java\64bit\jre6\bin\javaw.exe
leaving all the other arguments alone in the ini file; now, I could see that it was definitely using this particular javaw.exe but had exactly the same behavior I described above, edit a file (local filesystem, not network just to clear that it isn’t network related) and javaw.exe freaked out and Eclipse hung until forcibly killed.
I then tried changing the –vm argument in the eclipse.ini file to:
When Eclipse started it still had fired up javaw.exe in the Windows system32 directory as above. Whatever.
Finally, I invoked Eclipse using the command line –vm argument pointing to the JRE’s jvm.dll, like so:
D:\eclipse\eclipse.exe -vm C:\Java\64bit\jre6\bin\server\jvm.dll
and holy crap, it runs great. Responsive, no appreciable sluggishness, I even turned a bunch of the code assist and insight features back on in light of how great it works now. Because javaw.exe isn’t running I have seen none of the problems I had when using the default invocation. I don’t understand why this option isn’t talked about more (I recall seeing only one reference to it in all the stuff I read), nor why it works better for me than the default javaw.exe but I’ve been running it all day now and it has been working terrific so far.
So, if you’re on Win7 (or maybe even Vista) 64bit, have a 64bit JVM and 64Bit Eclipse and are seeing crappy performance or stability, try this method and see if it doesn’t solve your problems. Off now to uninstall IntelliJ and Komodo trials ….