Bug 21136 - Does not shutdown properly leaving zombie processes
Summary: Does not shutdown properly leaving zombie processes
Alias: None
Product: Runtime
Classification: Mono
Component: General ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2014-07-05 04:50 UTC by Matthias Mailänder
Modified: 2014-10-05 02:10 UTC (History)
5 users (show)

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

this is a not yet hung MonoDevelop instance log (55.00 KB, text/x-log)
2014-07-06 17:29 UTC, Matthias Mailänder
this one seemed to have hung for 3 hours and is not reacting to kill -QUIT (63.35 KB, text/x-log)
2014-07-06 17:30 UTC, Matthias Mailänder
gdb attach 2791 (20.03 KB, text/x-log)
2014-07-06 17:36 UTC, Matthias Mailänder
(gdb) t a a bt (2.04 KB, text/x-log)
2014-07-06 17:40 UTC, Matthias Mailänder

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 GitHub or Developer Community 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:

Description Matthias Mailänder 2014-07-05 04:50:49 UTC
Actually not really zombie processes as they still suck memory and are not marked as going to shutdown anytime soon. I only noticed that the game http://www.openra.net/ I was developing is slowing down a lot and my 4 GB Linux machine is suddenly trying to access a lot of SWAP space as an emergency measure. ALT + F2 in the KDE system monitor revealed that I amassed an army of mono and monodevelop processes eating memory. Force killing them helped. To reproduce you may need to work hard on your branch like rebasing a lot, changing .csproj files with text editors etc. It happens quite often for us though and most developers already downgraded to version 4 where this does not happen. This is http://paste.opensuse.org/view/simple/63043185 what KDE system monitor tells me when I ask for memory info.
Comment 1 Matthias Mailänder 2014-07-05 04:54:33 UTC
Closing MonoDevelop with ALT+F4 or hammering the [X] button and restarting it immediately may also trigger it as I am doing that quite often to workaround a problem where .csproj files are not reloaded properly and the build aborts claiming some files are missing etc.
Comment 2 Matthias Mailänder 2014-07-05 05:06:58 UTC
I forgot to tell that I have the StyleCop plugin http://addins.monodevelop.com/Project/Index/54 and Lua bindings installed.
Comment 3 Mikayla Hutchinson [MSFT] 2014-07-06 14:23:41 UTC
Can you please get backtraces of the hung processes?

Comment 4 Matthias Mailänder 2014-07-06 17:29:36 UTC
Created attachment 7283 [details]
this is a not yet hung MonoDevelop instance log
Comment 5 Matthias Mailänder 2014-07-06 17:30:33 UTC
Created attachment 7284 [details]
this one seemed to have hung for 3 hours and is not reacting to kill -QUIT
Comment 6 Matthias Mailänder 2014-07-06 17:36:05 UTC
Created attachment 7285 [details]
gdb attach 2791
Comment 7 Matthias Mailänder 2014-07-06 17:40:28 UTC
Created attachment 7286 [details]
(gdb) t a a bt
Comment 8 Mikayla Hutchinson [MSFT] 2014-07-06 21:05:33 UTC
Looks like the runtime is waiting for a pulseaudio or glib thread.
Comment 9 Mikayla Hutchinson [MSFT] 2014-07-06 21:05:53 UTC
What runtime version?
Comment 10 Matthias Mailänder 2014-07-07 01:29:45 UTC
Mono JIT compiler version 3.4.0 (tarball Thu May 29 06:29:11 UTC 2014)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug 
        LLVM:          supported, not enabled.
        GC:            sgen
Comment 11 Matthias Mailänder 2014-07-07 06:18:04 UTC
I think this happens when I close it while it is still searching for files that have changed like I switched branches using the command line.

Sometimes Amarok is running in the background, but I somehow don't believe this is pulseaudio related. It does not hook to the KMixer app and I also don't hear any sounds in MonoDevelop.
Comment 12 Mikayla Hutchinson [MSFT] 2014-07-07 10:55:25 UTC
The t a a bt trace appears to show that the Mono finalizer thread is waiting for all other threads to exit before it can shutdown. The only other threads are 2 glib threads and one pulseaudio thread. There's no managed code in the stacks at all.

Thread 6 (Thread 0x7f1fb811f700 (LWP 2793)):
#0  0x00007f1fbae330f0 in sem_wait () from /lib64/libpthread.so.0
#1  0x0000000000631907 in mono_sem_wait (sem=sem@entry=0x9854e0 <finalizer_sem>, alertable=alertable@entry=1) at mono-semaphore.c:119
#2  0x00000000005af50a in finalizer_thread (unused=unused@entry=0x0) at gc.c:1073
#3  0x000000000059186b in start_wrapper_internal (data=0x14c0c30) at threads.c:647
#4  start_wrapper (data=0x14c0c30) at threads.c:692
#5  0x000000000063616e in inner_start_thread (arg=0x7fff9469c740) at mono-threads-posix.c:94
#6  0x00007f1fbae2d0db in start_thread () from /lib64/libpthread.so.0
#7  0x00007f1fbab5d90d in clone () from /lib64/libc.so.6

Thread 5 (Thread 0x7f1fa98d2700 (LWP 2796)):
#0  0x00007f1fbab54b3d in poll () from /lib64/libc.so.6
#1  0x00007f1fb6a6c604 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f1fb6a6ca6a in g_main_loop_run () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f1fb4b77c16 in ?? () from /usr/lib64/libgio-2.0.so.0
#4  0x00007f1fb6a91035 in ?? () from /usr/lib64/libglib-2.0.so.0
#5  0x00007f1fbae2d0db in start_thread () from /lib64/libpthread.so.0
#6  0x00007f1fbab5d90d in clone () from /lib64/libc.so.6

Thread 4 (Thread 0x7f1fa90d1700 (LWP 2797)):
#0  0x00007f1fbab54b3d in poll () from /lib64/libc.so.6
#1  0x00007f1fb6a6c604 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x00007f1fb6a6c70c in g_main_context_iteration () from /usr/lib64/libglib-2.0.so.0
#3  0x00007f1fb6a6c759 in ?? () from /usr/lib64/libglib-2.0.so.0
#4  0x00007f1fb6a91035 in ?? () from /usr/lib64/libglib-2.0.so.0
#5  0x00007f1fbae2d0db in start_thread () from /lib64/libpthread.so.0
#6  0x00007f1fbab5d90d in clone () from /lib64/libc.so.6

Thread 3 (Thread 0x7f1f4f6d7700 (LWP 2811)):
#0  0x00007f1fbab54b3d in poll () from /lib64/libc.so.6
#1  0x00007f1f749d98c1 in ?? () from /usr/lib64/libpulse.so.0
#2  0x00007f1f749cb0ec in pa_mainloop_poll () from /usr/lib64/libpulse.so.0
#3  0x00007f1f749cb75e in pa_mainloop_iterate () from /usr/lib64/libpulse.so.0
#4  0x00007f1f749cb810 in pa_mainloop_run () from /usr/lib64/libpulse.so.0
Comment 13 Rodrigo Kumpera 2014-07-21 18:07:24 UTC
We have a possible fix for this on mono 3.6.0/master.

Could you try one of them?
Comment 14 Matthias Mailänder 2014-07-26 14:24:44 UTC
I was told there are continuous RPM test builds. Where can I find them? Everything at http://monojenkins.cloudapp.net/ and https://wrench.mono-project.com/Wrench/index.aspx seems to fail to build.
Comment 15 Matthias Mailänder 2014-10-05 02:10:45 UTC
I believe this was fixed as I can't reproduce it anymore. Thanks!