mono-sgen using 99% CPU in the background

[Ming-Tang]

I'm using OS X El Capitan. When I leave Vim with F# files open for too long, I observe a runaway process mono-sgen, very likely to be related with vim-fsharp. I couldn't use a debugger so I can't extract more information about it.

[kjnilsson]

Hi thanks for the report - tricky one to debug as you say. would you be able to give me a list of the vim-fsharp commands you typically use so I can do some targeted testing?

I have occasionally noticed the same after shutting the lid on my macbook and then opening it later.

[Ming-Tang]

I remember I added and removed files by edited the .fsproj compilation list within vim (<Compile Include="FILENAME.fs" />).

[Ming-Tang]

I just reproduced the bug, after editing compilation list. I closed Vim, one (out of two) mono-sgen processes is still running. Here are their loaded files.

/usr/local/Cellar/mono/4.2.0.179/bin/mono-sgen
/usr/local/Cellar/mono/4.2.0.179/lib/mono/4.5/mscorlib.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/4.5/mscorlib.dll.dylib
/Users/mingtang/.vim/bundle/vim-fsharp/ftplugin/bin/fsautocomplete.exe
/Users/mingtang/.vim/bundle/vim-fsharp/ftplugin/bin/FSharp.Core.dll
/Users/mingtang/.vim/bundle/vim-fsharp/ftplugin/bin/FsAutoComplete.Core.dll
/Users/mingtang/.vim/bundle/vim-fsharp/ftplugin/bin/FSharp.Compiler.Service.dll
/Users/mingtang/.vim/bundle/vim-fsharp/ftplugin/bin/NDesk.Options.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/System.Xml/4.0.0.0__b77a5c561934e089/System.Xml.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/Mono.Security/4.0.0.0__0738eb9f132ed756/Mono.Security.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/System.Core/4.0.0.0__b77a5c561934e089/System.Core.dll
/Users/mingtang/.vim/bundle/vim-fsharp/ftplugin/bin/Newtonsoft.Json.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/System.Runtime.Serialization/4.0.0.0__b77a5c561934e089/System.Runtime.Serialization.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/System.Numerics/4.0.0.0__b77a5c561934e089/System.Numerics.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/System.Xml.Linq/4.0.0.0__b77a5c561934e089/System.Xml.Linq.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/System.Data/4.0.0.0__b77a5c561934e089/System.Data.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/Microsoft.Build.Utilities.v12.0/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Utilities.v12.0.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/Microsoft.Build.Framework/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Framework.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/Microsoft.Build.Engine/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Engine.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/Microsoft.Build/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/Microsoft.Build.Tasks.v12.0/12.0.0.0__b03f5f7f11d50a3a/Microsoft.Build.Tasks.v12.0.dll
/usr/local/Cellar/mono/4.2.0.179/lib/mono/gac/Mono.XBuild.Tasks/12.0.0.0__0738eb9f132ed756/Mono.XBuild.Tasks.dll

[Ming-Tang]

Using a debugger on the runaway process terminates it.

(lldb) process attach --pid 11835
Process 11835 stopped
* thread #1: tid = 0x24e4e, 0x00007fff81597f5e libsystem_kernel.dylib`__psynch_cvwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff81597f5e libsystem_kernel.dylib`__psynch_cvwait + 10
libsystem_kernel.dylib`__psynch_cvwait:
->  0x7fff81597f5e <+10>: jae    0x7fff81597f68            ; <+20>
    0x7fff81597f60 <+12>: movq   %rax, %rdi
    0x7fff81597f63 <+15>: jmp    0x7fff815933ef            ; cerror_nocancel
    0x7fff81597f68 <+20>: retq

Executable module set to "/usr/local/bin/mono".
Architecture set to: x86_64h-apple-macosx.
(lldb) bt
* thread #1: tid = 0x24e4e, 0x00007fff81597f5e libsystem_kernel.dylib`__psynch_cvwait + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff81597f5e libsystem_kernel.dylib`__psynch_cvwait + 10
    frame #1: 0x00007fff93c8c73d libsystem_pthread.dylib`_pthread_cond_wait + 767
    frame #2: 0x000000010a516a96 mono`_wapi_handle_timedwait_signal_handle + 527
    frame #3: 0x000000010a524ccc mono`wapi_WaitForMultipleObjectsEx + 1573
    frame #4: 0x000000010a4a59d0 mono`wait_for_tids + 44
    frame #5: 0x000000010a4a5834 mono`mono_thread_manage + 515
    frame #6: 0x000000010a3a67bd mono`mono_main + 7200
    frame #7: 0x00007fff89b645ad libdyld.dylib`start + 1
    frame #8: 0x00007fff89b645ad libdyld.dylib`start + 1
(lldb)

[kjnilsson]

Hi - I have been seeing similar things myself now particularly with projects that have project references to other projects. What is your project structure for when you see this?

[Ming-Tang]

In my solution, there are two projects A and B and B references to A. Most times, I have files from both projects open.

[kjnilsson]

if in a new session you only open files from A then leave it - does it still happen?

[deapsquatter]

I've logged the same issue with a way to reproduce at FsAutoComplete

[andybak]

I just spotted high CPU usage by mono-sgen and I had no IDE's open. Could the Jetbrains Toolbox be the cause?

[jgartee]

I noticed the same thing after opening the Jetbrains ToolBox and selecting the "Update All" link. All open files seemed to be associated with the Rider.app, even though multiple other apps were updated. Restarting the system (obviously) stopped the process and it did not resume after accessing the Toolbox again. I'll repeat and report back the next time a Jetbrains update is available.