tracker issue : CFB-4130073

select a category, or use search below
(searches all categories and all time range)

Blizzard Crash / Memory Leak? Find and Replace Feature with File Encoding Issue

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/

Reporter/Name(from Bugbase): Travis Walters / Travis Walters (Travis Walters)

Created: 03/18/2016

Components: Performance

Versions: 2016

Failure Type: Unspecified

Found In Build/Fixed In Build: Beta1_v31 /

Priority/Frequency: Major / Unknown

Locale/System: English / Win All

Vote Count: 0

Problem Description:

Described below in great detail. Discussion in this thread:{B099ABD7-4284-4489-B8E2-839E0567F308}&topid={713996B7-C51B-4FAE-811B-258908230035}

IMPORTANT: This is a Blizzard Beta 2 bug but I could not set the build to Beta2 as only Beta1 exists in the dropdown.

Steps to Reproduce:

A few days back I had posted this thread here regarding a valid scenario for data loss in Blizzard due to autosaving files with a different file encoding (related to Bug #4099684):{E7CAEBDE-A8F5-4F52-B22D-E94600B746E8}&topid={3E201D69-1FFA-42F4-A96E-7905DB3D0C1E}

I guess about a week ago I filed another Bug (ID #4098760) where Blizzard was freezing due to the file search feature. This issue as well as the one above still exist in Blizzard Beta2 along with the issue I am about to describe.

I found a new bug today with Blizzard Beta2 that has to do with a major performance problem and potentially a memory leak that causes Blizzard to crash or error best case scenario.

I created a new workspace and project in Blizzard Beta2. This project has about 500,000 files and about 32,000 coldfusion related files. Due to the file encoding issue I originally encountered, I was forced to right click the project name in the navigator window, go to properties, and set the file encoding as ’ISO-8859-1’ so that when I use the find and replace feature it will not autosave the files as ’UTF-8’. At this point, after the file encoding has been set on the entire project, I use the file search to search for something like ’cfinclude template="/’, set the file name pattern to ’*.cfm’, and then click replace, it starts searching for instances of that text. At this point, when I click either the preview or OK button, the CPU will just churn and nothing happened. In fact, I let it sit there awhile and my computer shut down (tried this on multiple occasions with the same result). At this point, I looked at the CFBuilder.ini and noticed that the memory the program can use is extremely low considering I have 32 GB of RAM available. I tweaked the file a bit for testing purposes to:


I am by no means an expert at tweaking these values so please feel free to yell at me if I did something incorrect =)

Moving forward, I opened Blizzard Beta 2 and tried the same procedure as before. CPU did not churn as much but I noticed if I opened Task Manager, the memory keeps increases until it eventually crashes quite awhile later. The find and replace feature never works so it was all for nothing at this point.

Having said that, if I do not set the file encoding to ’ISO-8859-1’ and leave it as it was by default ’UTF-8’, the find and replace feature will work but it will autosave the files with the ’UTF-8’ file encoding and special characters from the ’ISO-8859-1’ will be lost. 

I feel like I am in a no win situation here up a creek without a paddle. I realize that the file encoding issue was a valid scenario and the issue was deferred, but if developers that purchase this software start encountering data loss for whatever reason, hanging programs, and simple features like find and replace that do not work, it would not even be worth purchasing the program. At this point, I cannot even use the program to work on this employer’s code and would be forced to look for another program. It is not uncommon for a company to outsource work to a programmer in another country that would not use ’UTF-8’ as their file encoding and then have somebody local make minor tweaks down the road. I have to believe it would be more than myself encountering these issues. 

Can you do something here Adobe to make this scenario better for all involved? 

Actual Result:

Crash, Error, Memory Leak?, Bad Performance, Frustration

Expected Result:

Find and Replace work correctly when different file encoding used.

Any Workarounds:

Not really because of the auto-saving the files to a different file encoding results in data loss.

Food for thought: On the initial installation, can you set the memory the application can use to be a bit higher or even a percentage of the total memory for better performance?

Not sure if this will help but when it errors instead of crashing (after increasing the memory quite a lot), it had some java heap error (probably memory) and something about an error occurring during refactoring. 

Other than that, I am using Windows 10 Pro.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	4130073

External Customer Info:
External Company:  
External Customer Name: Travis Walters
External Customer Email: TWALTERS84@HOTMAIL.COM
External Test Config:



Added By: PreRelease User User Name:Travis Walters Note Added: Entered Bug. Date Added :2015-12-22 17:30:09.0
Comment by CFwatson U.
26550 | March 18, 2016 05:25:01 AM GMT
This bug has two parts to be precise. First: Performance related: while using search and replace in file search, builder hangs. Issue is similar to File Search in large projects, which is being tracked as bug#4130081. The performance hit is with Eclipse also but for little relief user can do following things to improve performance. Use Builder as plugin to Mars(Eclipse Mars has fixed few performance issues) and when search starts, minimize the search results view, this will increase the performance and builder will not hang. For actual fix please follow the bug#4130081. Second: When user changes the encoding of the project and uses replace feature, he faces data loss. This is Eclipse functionality. If your file contains non-utf8 characters and you forcefully try to change the file encoding, data loss is bound to happen. So we strongly recommend to not go this path as this is by design. To fix original issue of performance please follow bug#4130081
Comment by Milan C.
26551 | May 18, 2016 04:06:45 AM GMT