mrward/monodevelop-dnx-addin

v0.1.1 - Too many open files errors/dialogs

nathanielcook opened this issue · 7 comments

Thanks for putting together v0.1.1 which has the "Automatically restore dependencies" checkbox on the preferences page. Since unchecking that checkbox I haven't seen the project.json.lock file updated, so that seems to be working so far. Unfortunately I haven't been able to get very far though because I ran into a couple of other problems. The main problem seems to be that I frequently get messages related to "too many open files".

In the solution pad:
screen shot 2016-01-15 at 12 17 08 pm

Activation dialog:
screen shot 2016-01-15 at 11 43 45 am

It happens (albeit intermittently) upon opening the project. I haven't changed my version of Visual Studio or Mono (4.3.2 (master/ac69bf1 Thu Jan 7 09:41:02 EST 2016)) since trying v0.1.

The other problem is more minor; I will post that in a separate issue.

Can you attach the callstack from the IDE log (Help - Open Log Directory)? The callstack from the activation dialog does not really show what triggered the too many open files, however the callstack when the project is opened should have the full callstack logged with the message "DNX project system initialize failed".

Looking at another bug report for the too many open files error suggests that you might be able to get around this by setting the MONO_MANAGED_WATCHER environment variable and then running Xamarin Studio from the command line. They suggest setting it to disabled but that will most likely stop DNX from detecting file changes so you could try setting it to false.

export MONO_MANAGED_WATCHER=false

I have not hit a kqueue() FileSystemWatcher has reached the maximum number of files to watch error when loading a DNX solution with lots of files. Setting MONO_MANAGED_WATCHER to false fixed this particular problem for me with Mono 4.2.

Here are my logs from Friday: logs.zip (This is a side project I am working on just one day a week.) If you like I can try the environment variable workaround this Friday; let me know. You'll see information in the logs relating to this issue and this one as well. Will look forward to hearing if you find anything in the logs that helps track down the exact causes for those issues.

By the way, not sure if it makes a difference, but if I recall correctly I disabled v0.1, then uninstalled v0.1 before installing v0.1.1.

From the logs I can see that the you started Xamarin Studio and then straight away on opening your DNX solution you have the too many files open error message.

ERROR [2016-01-15 11:43:37Z]: DNX project system initialize failed.
System.IO.IOException: Too many open files
  at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00335] in /private/tmp/source-mono-master/bockbuild-xamarin/profiles/mono-mac-xamarin/build-root/mono-x86/mcs/class/corlib/System.IO/FileStream.cs:290 
  at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] in /private/tmp/source-mono-master/bockbuild-xamarin/profiles/mono-mac-xamarin/build-root/mono-x86/mcs/class/corlib/System.IO/FileStream.cs:97 
  at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
  at System.IO.File.OpenRead (System.String path) [0x00000] in /private/tmp/source-mono-master/bockbuild-xamarin/profiles/mono-mac-xamarin/build-root/mono-x86/mcs/class/corlib/System.IO/File.cs:341 
  at OmniSharp.Dnx.DnxPaths.GetRuntimeVersionOrAlias (System.String globalJson) <0x13beeac8 + 0x0008f> in <filename unknown>:0 
  at OmniSharp.Dnx.DnxPaths.GetRuntimePath () <0x13bedf08 + 0x0005f> in <filename unknown>:0 
  at OmniSharp.Dnx.DnxPaths..ctor (IOmnisharpEnvironment env, OmniSharp.Options.OmniSharpOptions options, ILoggerFactory loggerFactory) <0x13bedad8 + 0x00093> in <filename unknown>:0 
  at OmniSharp.Dnx.DnxProjectSystem..ctor (OmniSharp.OmnisharpWorkspace workspace, IOmnisharpEnvironment env, IOptions`1 optionsAccessor, ILoggerFactory loggerFactory, IMetadataFileReferenceCache metadataFileReferenceCache, IApplicationLifetime lifetime, IFileSystemWatcher watcher, IEventEmitter emitter, OmniSharp.Dnx.DnxContext context) <0x13bed300 + 0x0011f> in <filename unknown>:0 
  at MonoDevelop.Dnx.DnxProjectSystemFactory.CreateProjectSystem (MonoDevelop.Projects.Solution solution, IApplicationLifetime appLifetime, OmniSharp.Dnx.DnxContext context) <0x13bec560 + 0x00197> in <filename unknown>:0 
  at MonoDevelop.Dnx.DnxProjectService.LoadDnxProjectSystem (MonoDevelop.Projects.Solution solution) <0x13bebf78 + 0x000d7> in <filename unknown>:0 
  at MonoDevelop.Dnx.DnxProjectService.OnSolutionLoaded (MonoDevelop.Projects.Solution solution) <0x13bebc18 + 0x0003b> in <filename unknown>:0 

Then Xamarin Studio is in a bad state since any file it tries to open and update will then fail.

What is interesting about the callstack is that the DNX host has not started at this point so not many files should have opened yet. The first it does is tries to find the global.json for the solution and read it. So I do not really know what has all the file handles. It may possibly not be Xamarin Studio but another process. Maybe running lsof will show what has lots of files open.

Thanks for the tip on lsof. That helped me see that Xamarin Studio was opening all the files in the .git directory. By moving the sln file one level down I was able to avoid the problem. That being the case I think you may want to consider adjusting the default project structure. The default project structure is

screen shot 2016-01-22 at 1 38 50 pm

But having the sln file in the root causes the files in the .git directory to get loaded (verifiable using lsof, as you suggested). I suggest the following (which is what I ended up doing):

screen shot 2016-01-22 at 1 39 10 pm

The problem is not obvious for new projects since there are not very many files in the .git directory yet. But if you have an existing repository with many files and commits like I do then I guess that's when the problem happens.

I think this issue can be closed, unless you want to change the default project structure, or unless there is a way to avoid having Xamarin Studio load all the files in the .git directory. Thanks for your help.

Just wanted to let you know that, after making the aforementioned change, I used Xamarin Studio with v0.1.1 all day today to work on my project, and it worked great! No crashes or problems, and it's so nice to be able to debug again.

I do not plan to change the folder structure since it is based on what Visual Studio creates.

However this does look like a bug in the DNX addin. Xamarin Studio's Git addin does not load many files from the .git directory. Also if you disable version control then it does not load any.

I did a quick test using monodevelop's source from GitHub and put a DNX project in the root directory, to mirror your original setup. On opening the DNX project, with version control disabled, I get the kqueue() FileSystemWatcher has reached the maximum number of files to watch error.

Currently the DNX addin creates a file watcher that uses the solution's directory as the starting point. So this will mean it will be looking in all subdirectories including the .git directory, even though there is no need to look at this directory. So my first thought is to change the DNX addin so it watches the sources directories as defined in the global.json file and ignores the solution directory.

That makes sense. Could provide a performance boost as well.