Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
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 $
Created attachment 3773 [details]
This is the result of repeated searches in project, directories, and solution.
Created attachment 3776 [details]
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.
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?
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.
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)
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.
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)
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.
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.
3) and if you do let's say 5 searches - why does search 1 leak ?
Sure, it's not an actual leak, but it's still potentially very bad, and looks very much like a leak in practice :)
1) There's no mimetype for .pack files, why were they considered text files?
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.
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.
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.
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.
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.
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.
Created attachment 3783 [details]
Exception in thread "Thread-1" java.lang.OutOfMemoryError: Java heap space
Warning: Degraded allocation. Consider increasing nursery-size if the warning persists.
Stack overflow in unmanaged: IP: 0x10f3ec, fault addr: 0xb07c1fdc
Mike - I imagine (3) loads all the documents because it's measuring the size?
(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
>* 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...).
> 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.
Well, I found why .pack object were considered text. Apparently, DesktopService.GetMimeTypeForUri returns text/plain for unknown files :/
Fixed the text detection.
3) Y it's the text measure - that's why it's hard to fix - I need a new/other control for that.
@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.
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.
Should be fixed in 22.214.171.1244
(The text measurement issue was already fixed before btw.)