Bug 11661 - Search result window can run out of memory
Summary: Search result window can run out of memory
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: 4.0.3
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Mike Krüger
URL:
Depends on:
Blocks:
 
Reported: 2013-04-08 20:04 UTC by Stephen Shaw
Modified: 2015-06-04 02:38 UTC (History)
5 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
output_redirected_to_file (1.25 MB, text/plain)
2013-04-08 20:18 UTC, Stephen Shaw
Details
output_redirected_to_file_1 (1.37 MB, text/plain)
2013-04-08 22:10 UTC, Stephen Shaw
Details
Apple crash report output (87.08 KB, text/plain)
2013-04-09 13:12 UTC, Stephen Shaw
Details
This is the console output for attachment 3 (3.03 MB, text/plain)
2013-04-09 13:18 UTC, Stephen Shaw
Details
More output (49.60 KB, text/plain)
2013-04-09 13:22 UTC, Stephen Shaw
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Stephen Shaw 2013-04-08 20:04:03 UTC
Unfortunately, I'm short on details, but this is getting bad enough that I need to file a bug and see what we can get figured out. The fact that XS crashes is slowly becoming a popular topic around here. It seems like it runs out of memory (3.5 G used).

We are using the alpha channel (on android at least) and it seems to have become bad as of late. When it crashes there is the apple dialog asking if we want to report the crash. Its probably happens 1+ times a day. I'll try and grab the output next time.
Comment 1 Stephen Shaw 2013-04-08 20:15:59 UTC
Doing repeated searches will cause XS to crash:

sgshaw@sgshaw_pro:/Applications/Xamarin Studio.app/Contents/MacOS/lib/monodevelop/bin $ mono-sgen XamarinStudio.exe --no-redirect > ~/tmp/XS_output.txt
System.OutOfMemoryException: Out of memory
  at (wrapper managed-to-native) string:InternalAllocateStr (int)
  at System.String.CreateString (System.Char[] val) [0x00000] in <filename unknown>:0
  at (wrapper managed-to-managed) string:.ctor (char[])
  at System.Text.Encoding.GetString (System.Byte[] bytes, Int32 index, Int32 count) [0x00000] in <filename unknown>:0
  at System.Text.UTF8Encoding.GetString (System.Byte[] bytes, Int32 index, Int32 count) [0x00000] in <filename unknown>:0
  at System.Text.Encoding.GetString (System.Byte[] bytes) [0x00000] in <filename unknown>:0
  at MonoDevelop.Ide.FindInFiles.FileProvider.ReadString () [0x00000] in <filename unknown>:0
sgshaw@sgshaw_pro:/Applications/Xamarin Studio.app/Contents/MacOS/lib/monodevelop/bin $
Comment 2 Stephen Shaw 2013-04-08 20:18:19 UTC
Created attachment 3773 [details]
output_redirected_to_file

This is the result of repeated searches in project, directories, and solution.
Comment 3 Stephen Shaw 2013-04-08 22:10:54 UTC
Created attachment 3776 [details]
output_redirected_to_file_1

This time it was largely just deploy, make some changes, redeploy.  It didn't crash, but when code changed outside of XS, I had to force close it. Watching the activity monitor, with each deploy more memory was being consumed and not freed.
Comment 4 Mikayla Hutchinson [MSFT] 2013-04-08 23:04:50 UTC
We're getting a bunch of these from GTK due to giving it bad markup, maybe it leaks in that case?

WARNING [2013-04-08 18:11:16Z]: Gtk-Warning: Failed to set text from markup due to error parsing markup: Error on line 1 char 661: Element 'markup' was closed, but the currently open element is 'span'

We definitely need to fix the markup to eliminate it as a possible cause and clean up the logs.

We're also getting:
Error while opening /Users/sgshaw/code/xactware/git/.git/objects/pack/pack-0bfc5a3535b43d5b770f8506f5b0f679581b2602.pack
System.IO.IOException: Reading more than 2GB with this call is not supported
  at System.IO.File.ReadAllBytes (System.String path) [0x00000] in <filename unknown>:0 
  at MonoDevelop.Ide.FindInFiles.FileProvider.ReadString () [0x00000] in <filename unknown>:0 

Which seems really bad - it implies it's probably opening a vast number of large-but-not-quite-2gb files, which will create a ton of GC pressure. Why is find in files trying to open these enormous blobs as text? Why is it even looking in the .git directory?

* we should consider having a (configurable?) cap on the size of the files the search can open
* we should make sure we don't keep references to giant strings. For example, https://github.com/mono/monodevelop/blob/master/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.FindInFiles/SearchResultWidget.cs#L579 keeps a dictionary of entire documents, which could easily get enormous. Maybe it could truncate rendered results to 1000chars and cache those? Discard documents that are not used by any lines within view? 
* we should consider fixing https://bugzilla.xamarin.com/show_bug.cgi?id=2055
* we should make "ignore hidden files" also ignore hidden directories 
* we should make a "find in project directories" that just looks at the files in the project.

Stephen, do you have your search set to look in binary files, or are we misdetecting the type of the .pack files?
Comment 5 Stephen Shaw 2013-04-08 23:17:37 UTC
I didn't change any settings. The settings I used in this test were all the defaults that come up when you hit cmd-shift-f. I did switch btween project, solution, and directories.
Comment 6 Mike Krüger 2013-04-09 02:43:58 UTC
Mhutch: only documents are stored that have lines which contain search results. For highlighting the whole document needs to be scanned. And the document list is cleared for new searches.

The problem isn't the 1st search it's the nth as far as I understand him (in chat).

The cause that this problem appears is that the .git directories got included every time. I fixed that.
(Unfortunately it's not the real cause of the problem, it makes it only visible)

1)
The binary detection is atm done by mime type - but I consider using the text file utility binary detection for that - I'll look into it.

2)
The strings are generated on demand (it's costly to highlight all files) therefore I don't think that matters - even if they leak it's just around 100-200 bytes each. (But y they need to be fixed)

3)
I think we're running into a GC problem here - the documents are stored in memory, yes  - but they're discarded at every new search.
Comment 7 Mikayla Hutchinson [MSFT] 2013-04-09 03:28:25 UTC
3) It's not a GC problem. The pad keeps a Dictionary<string, TextDocument> () containing all the documents for results that were ever scrolled into view - and it's kept until the user does another search or explicitly clears the list. So, if you have 1GB of "text" files, and scroll the list, you will lose 1GB of memory until you search again.
Comment 8 Mike Krüger 2013-04-09 03:29:11 UTC
3) and if you do let's say 5 searches - why does search 1 leak ?
Comment 9 Mikayla Hutchinson [MSFT] 2013-04-09 03:31:53 UTC
Sure, it's not an actual leak, but it's still potentially very bad, and looks very much like a leak in practice :)

Also:
1) There's no mimetype for .pack files, why were they considered text files?
Comment 10 Mike Krüger 2013-04-09 03:33:36 UTC
3) btw. the documents are not generated for all search results - only for the ones that get requested through scroll. Therefore I don't see much of a problem here - esp. if you've many search results.
Comment 11 Mike Krüger 2013-04-09 03:35:36 UTC
1)

if (!IncludeBinaryFiles && !DesktopService.GetMimeTypeIsText (DesktopService.GetMimeTypeForUri (fileName)))

there is no real reason why pack files get included. But maybe it's better to use the text file service binary detection in additon to the mime type. I currently investigate that.
Comment 12 Mike Krüger 2013-04-09 04:06:50 UTC
hm, ok I think 3) is the problem - it should be lazy, but it isn't gtk requests all documents :/

-> that shouldn't be done ... 


btw. I improved the binary check with the text file utility ... therefore this special problem shouldn't occur anymore - but the search result widget needs to work differently.
Comment 13 Mike Krüger 2013-04-09 04:44:50 UTC
Setting to enh. - I consider 75% of the bug as fixed - but the underlying problem that the search result window has a bad design remains.

... I want to redo it since my initial implementation of it but never found the time/patience. But may some nice item for phase 2 of ui-refresh.
Comment 14 Stephen Shaw 2013-04-09 13:12:35 UTC
Created attachment 3781 [details]
Apple crash report output

I had just closed a solution, updated the code outside of XS, started loading the solution and it crashed.
Comment 15 Stephen Shaw 2013-04-09 13:18:35 UTC
Created attachment 3782 [details]
This is the console output for attachment 3 [details]

This is the console output for attachment 3 [details] and the previous comment.
Comment 16 Stephen Shaw 2013-04-09 13:22:07 UTC
Created attachment 3783 [details]
More output

Exception in thread "Thread-1" java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOfRange(Arrays.java:3209)
	at java.lang.String.<init>(String.java:215)
	at com.android.ide.common.resources.ValueResourceParser.characters(ValueResourceParser.java:195)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.characters(AbstractSAXParser.java:538)
	at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:464)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:808)
	at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
	at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:119)
	at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
	at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
	at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
	at javax.xml.parsers.SAXParser.parse(SAXParser.java:198)
	at com.android.ide.common.resources.MultiResourceFile.parseFile(MultiResourceFile.java:170)
	at com.android.ide.common.resources.MultiResourceFile.load(MultiResourceFile.java:64)
	at com.android.ide.common.resources.ResourceFolder.processFile(ResourceFolder.java:98)
	at com.android.ide.eclipse.adt.internal.resources.manager.ResourceManager.createProject(ResourceManager.java:513)
	at mono.android.Project.reloadResources(Project.java:82)
	at mono.android.Project.<init>(Project.java:71)
	at mono.android.AndroidDesignerHost.loadProject(AndroidDesignerHost.java:74)
	at mono.android.AndroidDesignerHost.processMessage(AndroidDesignerHost.java:88)
	at mono.android.ListenerThread.processMessages(HostProcessConnection.java:159)
	at mono.android.ListenerThread.run(HostProcessConnection.java:133)
Warning: Degraded allocation.  Consider increasing nursery-size if the warning persists.
Stack overflow in unmanaged: IP: 0x10f3ec, fault addr: 0xb07c1fdc
Comment 17 Mikayla Hutchinson [MSFT] 2013-04-09 13:51:25 UTC
Mike - I imagine (3) loads all the documents because it's measuring the size?
Comment 18 Andres G. Aragoneses 2013-04-09 13:55:55 UTC
(In reply to comment #4)
> Why is find in files trying to open these enormous blobs as text?
> Why is it even looking in the .git directory?

Maybe because the default filter for Find in files is or it used to be "Directories"? I reported this at some point and not sure it was fixed only in master, or not fixed yet, or closed as wontfix (it's "Current Project" as default according to my testing now; shouldn't it be Whole solution?)

> * we should make "ignore hidden files" also ignore hidden directories 

+1

>* we should make a "find in project directories" that just looks at the files
in the project.

What's wrong with the "Current project" filter? Doesn't that one cover your needs? IMO if Current Project is not enough for your search, then you want a much broader search (but not as massive as searching in the .git folder...).
Comment 19 Mikayla Hutchinson [MSFT] 2013-04-09 16:42:28 UTC
> What's wrong with the "Current project" filter? Doesn't that one cover your
> needs? IMO if Current Project is not enough for your search, then you want a
> much broader search (but not as massive as searching in the .git folder...).

No. Firstly, it's impossible to search in a subfolder of a project. Secondly, "find in files" on the context menu in the solution tree searches on disk, not in the thing I selected in the solution tree.

And let's not derail this bug. I brought it up since it would have have prevented the overbroad search that caused massive memory use, but it's not what this bug is about.
Comment 20 Mikayla Hutchinson [MSFT] 2013-04-09 17:34:26 UTC
Well, I found why .pack object were considered text. Apparently, DesktopService.GetMimeTypeForUri returns text/plain for unknown files :/
Comment 21 Mikayla Hutchinson [MSFT] 2013-04-09 20:28:35 UTC
Fixed the text detection.
Comment 22 Mike Krüger 2013-04-10 02:16:42 UTC
3) Y it's the text measure - that's why it's hard to fix - I need a new/other control for that.
Comment 23 Mike Krüger 2013-11-27 02:03:02 UTC
@David: Any input on a new fancy design for the search results ?

btw. I would like to have something like the SharpDevelop search result window that shows the search results in a tree rather than a list - this way the user can group the search results by files/projects etc. more easily - if whished.
Comment 24 Miguel de Icaza [MSFT] 2013-11-27 14:02:01 UTC
Mike,

Can you share the screenshots of what SharpDevelop does with that tree?

I do not really like trees for this kind of selection, it sounds like we should have a different way of filtering.
Comment 25 Mike Krüger 2015-06-04 02:38:01 UTC
Should be fixed in 6.0.0.2504

(The text measurement issue was already fixed before btw.)