GNOME Bugzilla – Bug 573291
banshee is leaking threads
Last modified: 2011-06-15 07:45:17 UTC
I leave banshee up and running for long periods of a time (weeks). Over this period of time, banshee starts more and more threads and they stay alive. This may be related to the podcast plugin, which is the only activity that occurs regularly. A newly started version of banshee uses 500 Megs of virtual memory and about 40 Megs of resident and has about 10 threads running. After running for 2 weeks, it has risen to 1.5 Gigs of Virtual and 300 Megs resident. There are also a very large number of threads running (50-100)
Please tell us the name of the distro and version of Mono (show the output of 'mono --version'). Thanks.
Please trigger a thread dump as well. See http://banshee-project.org/contribute/file-bugs for information. Andres, don't forget to set as NEEDINFO when appropriate.
Sorry, here are my system specs: I'm running 64 bit Ubuntu 8.10, on a Q6600 with 4 Gigs of RAM ubuntu64bu307:~> mono -V Mono JIT compiler version 1.9.1 (tarball) Copyright (C) 2002-2007 Novell, Inc and Contributors. www.mono-project.com TLS: __thread GC: Included Boehm (with typed GC) SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none When I left this computer last night there were 21 threads, and it was using about 600 Megs Virtual. This morning it has 23 threads and about 700 Megs Virtual. Here is the log file: exec -a banshee-1 mono /usr/lib/banshee-1/Banshee.exe --redirect-log --play-enqueued [Info 11:03:54.237] Running Banshee 1.4.2: [Ubuntu 8.10 (linux-gnu, x86_64) @ 2009-01-22 07:54:34 UTC] No protocol specified (Banshee:15336): Gtk-WARNING **: cannot open display: :0.0 but I'm not sure that is the correct log file. I rebooted my computer yesterday because it was acting strangely, (I could not open new X windows). This looks like the log from before the reboot. Can I restart banshee with debugging enabled to capture more output? If so I can leave it running over the weekend. I expected more threads will be created.
Yes, run it with --debug
I left banshee running overnight (with mono 2.2) and the thread dumps (with kill -s QUIT) before and after did not show any increase in the number of threads (the usual 6). Darin, how are you measuring the number of threads ?
I've been using htop and ps. Does the podcast plugin start new threads when it downloads feeds or files? Usually I leave banshee paused while away, so the only thing that is happening is the check for and download of new podcasts. If a feed or a download times out (or has some other error), do the threads get cleaned up properly?
Created attachment 129862 [details] debugging output from banshee This shows a few exceptions occurring during the run.
Here are banshee's threads from start up to when the log file was taken. ubuntu64bu307:~> date; ps -L -p 13721 -o pid,vsz,rsz,cmd Mon Mar 2 08:27:14 EST 2009 PID VSZ RSZ CMD 13721 466952 104912 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 466952 104912 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 466952 104912 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 466952 104912 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 466952 104912 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 466952 104912 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 466952 104912 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 466952 104912 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 466952 104912 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 466952 104912 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 466952 104912 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug ubuntu64bu307:~> date; ps -L -p 13721 -o pid,vsz,rsz,cmd Mon Mar 2 11:38:39 EST 2009 PID VSZ RSZ CMD 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug 13721 557880 152148 banshee-1 --debug /usr/lib/banshee-1/Banshee.exe --debug --debug
Darin, could you run the command given at http://banshee-project.org/contribute/file-bugs/ after banshee has been running for some time ? The "kill -s QUIT $(pidof banshee-1)" command tells banshee (the mono runtime, actually) to output information about each thread. Could you also try to disable the Podcast extension, and see if it has an influence on your problem ?
Created attachment 130013 [details] Banshee debug output with thread dump Here is the log from this morning, with the kill -s QUIT thread dump. At this point, I now have 32 threads running and about 850 Megs virtual and 240 Megs resident. I shut it down and restart with the podcast plugin disabled.
I've been doing some more experimentation with this issue, and it seems like whenever I skip to a new song, a new thread is started. Sometimes a few threads will go away, but more often the total thread count increases. Occasionally it will increase by a lot (say 6 threads). On my machine at home (which is also an x86 64, Ubuntu 8.10, running banshee 1.4.2), I see the threads increase to 21 and then drop down to 17, then increase to 21, then drop again (repeat). On my work machine, the thread count keeps increasing, occasionally jumping up by 6 and occassinoally dropping by about 3 or 4, but overall more threads are created then are stopped. I'll try disabling all the plugins and experiment again. I am going to attach the banshee debug log, with thread dump, and a log of the number of threads banshee is using, collected using: date >> banshee.pslog ; ps -L -p 17150 -o pid,vsz,rsz,cmd | wc >> banshee.pslog where 17150 is the pid of banshee.
Created attachment 130131 [details] A log of the banshee threads This a log of the number of threads used by banshee. Between each entry I pressed skip forward in banshee.
Created attachment 130132 [details] The debug log file associated with the log of banshee threads
I see the same behaviour with all the plugins disabled. Skipping tracks seems to create new threads.
You said you had 32 threads at the time you made that thread dump, but it only showed ~ 12.
From what I can see ps reports more threads than the thread dump does. So if you look at the log I generated with ps, banshee started with 8 threads, and ended with 61, however the thread dump at the end of the corresponding debug log only shows 5 tids (which I assume are the threads).
I don't know much about the internals of the mono runtime, but my guess is that the mono process has threads that are not really part of the running application (garbage collection and stuff) and not shown in "-s QUIT" thread dumps. On my system, with banshee 1.4.2 and mono 2.2, skipping track doesn't lead to an increase of the number of threads given by "ps -L". After the first track has started to play, the number of threads stays at 16. I'm starting to think this could be a mono bug that has been fixed in 2.2.
Also, GStreamer's threads aren't shown by the Mono thread dump. Darin, you mentioned earlier that this thread # increase happened even when you left Banshee idle (paused) overnight - eg it wasn't caused (only) by 'next song', right?
Is this resolved yet? I cant recreate it however i remember a 1.x.x version i used having this issue than it just disappeared around the 1.9 or 1.8 series.
Setting to NEEDINFO per Dave's last comment.
Please feel free to reopen this bug if the problem still occurs with a newer version of Banshee 2.0.0.