Crash using Find in Files on large repositories, Sprint 34 #6091
Comments
|
I've come across this issue also, but with no shareable statistics other than I'm also running on 16GB of RAM. |
|
We have an upper limit for number of files indexed, but in this case it sounds like the problem is there's a smaller number of files but they are very large in size. At the very least we should filter out image files from Find in Files -- seems like that would help in this scenario. @Krindi can you clarify though, what you mean by "multiple attempts to find a .jpg in this repository"? Find in Files searches for text within a file, so you couldn't use it to search for an image file (or any other non-text file). To search for files by file name, you should use Quick Open -- which is many, many times faster. |
ghost
assigned 
|
@peterflynn it does sound like he's trying to actually find a jpg. If images aren't already filtered out of find in files it definitely should be. |
|
@peterflynn Sorry if I wasn't clear enough. I was using Find in Files to determine what file an image was used in, i.e. searching for text within text files. My suspicion was that non-text files (images and PDFs in my case) were impacting the search result. Perhaps having an option in Find in Files to specify a set of file types to search within? (That's customizable?) |
|
Clicked wrong button and closed by accident. |
|
In my case I was searching for "string_based_name" in all files within a project/folder. 1700+ files, including images but my intention was to search within text based files. Just in case that helps. |
|
I don't know any reason why to search within pictures, as the raw output isn't human-readable normally, so maybe we should ignore images at all (not only as a setting). |
|
@Krindi Does this issue still happen in recent versions of Brackets? We should no longer be reading image files during a search operation. Closing for now on that assumption, but please let me know if you're still seeing problems and I'll reopen this. |
|
@peterflynn It's sort of resolved now. The addition of a filter helped narrow down the problem. i.e. Sometimes "Brackets has stopped working" pops up, sometimes it's also accompanied with an Application Error: In either case, the program closes after interacting with the dialog box. The project I'm searching within has 2842 files. I did some more testing, and if I filter it to exclude ".svn" and "*.pdf" then the Find in Files works not just correctly, but almost instantly - the behavior I had originally expected. So that's a work around for now. If I only have one or the other filtered then the program still crashes. Whether or not image files are filtered has no effect, so seems to be correctly filtering those out. Some relevant details on the project I was testing with: |
* Recognize a wider variety of HTML templates embedded in script tags * Remove generic "clike" language declaration that no files map to - seems unneeded, and clutters the dropdown in PR #6409 * Add missing commenting syntax to Scala language * Automatically filter out a variety of common binary file types from Find in Files (it already checks isBinary) - note that this does not affect Mac, where all binary file IO fails automatically. Helps reduce bugs like #6091. Leaves the ProjectManager.isBinary() API in place for now, since it also excludes files from Quick Open and other getAllFiles() clients that don't yet check isBinary via LanguageManager. * Fix incorrect code in Find in Files that only narrowly avoids creating bugs where filtered-out files are incorrectly added to search results.
|
@Krindi Are you sure the .svn part is required in your filter? Brackets should be filtering out .svn folders automatically (you shouldn't even see it listed in the project folder tree, for example). If filtering *.pdf alone isn't enough to fix this, please let me know -- I'd like to reopen and do some investigation about why .svn isn't getting excluded automatically. |
|
On 3/21/2014 3:19 PM, Peter Flynn wrote:
@peterflynn You're correct, repeating the test today indicates that the |
|
Whew! I'm glad to hear it :-) Fwiw, I'm trying to get a fix into the next build to be smarter about auto-excluding common binary types like .pdf (currently we only exclude images, which are probably the most common binary type in web projects, but far from the only -- as you've demonstrated). |
|
PR #7290 should prevent this particular case from recurring, and this user story should help block binary files from taking up memory more generally. |
* Recognize a wider variety of HTML templates embedded in script tags * Remove generic "clike" language declaration that no files map to - seems unneeded, and clutters the dropdown in PR adobe#6409 * Add missing commenting syntax to Scala language * Automatically filter out a variety of common binary file types from Find in Files (it already checks isBinary) - note that this does not affect Mac, where all binary file IO fails automatically. Helps reduce bugs like adobe#6091. Leaves the ProjectManager.isBinary() API in place for now, since it also excludes files from Quick Open and other getAllFiles() clients that don't yet check isBinary via LanguageManager. * Fix incorrect code in Find in Files that only narrowly avoids creating bugs where filtered-out files are incorrectly added to search results.
Using Control + Shift + F (Edit > Find in Files) in a large repository causes a program crash.
Sprint 34 with no extensions
Size of repository : 2.34 GiB, very image heavy, 2606 files in 310 folders
Live Preview : not being utilized
Site in question was originally written in ASP.NET from Visual Studio 2012, if that matters.
"The exception Breakpoint
A breakpoint has been reached.
(0x80000003) occurred in the application at location 0x55e758e0
Click on OK to terminate the program"
The error message doesn't always occur, sometimes just "Brackets has stopped working". When the Application Error message comes up, two hex numbers were the same 100% of the time.
Memory usage with the repository open is around 9 MB, during multiple attempts to find a .jpg in this repository the highest memory usage witnessed was 915 MB. Usually it hit's "not responding" when it clears 200 MB memory use, and crashes after some variable period of time.
Running the same test against a smaller repository of 277 MB, but still image heavy, showed interesting behavior. The "Find in Files" took 28 seconds to complete, and disk activity reached as high as 19 MB/s.
My system has 16 MB of RAM, and CPU utilization during the crash out doesn't exceed 12%. For comparison, the same search in Visual Studio 2012 takes less than 2 seconds and increases RAM utilization by approximately 3 MB, and there is no disk activity.
The text was updated successfully, but these errors were encountered: