GNOME Bugzilla – Bug 664073
gst-plugin-scanner hangs, eating CPU time
Last modified: 2013-08-16 16:19:59 UTC
Created attachment 201402 [details] strace of the runaway gst-plugin-scanner We run Linux Terminal Servers (LTSP) at a German school, for approx. 800 users. The servers run standard Edubuntu. I frequently see a lot of "gst-plugin-scanner" processes running on our servers, without ever terminating, and eating up CPU time. Since many users log into the same server, this easily pulls up the load to 10 or above, basically killing the servers and frustrating the users (and admin). The runaway processes remain when the user logs out. Is there any other reason why "gst-plugin-scanner" should fail so badly in an LTSP-environment? I should add that the problem remains when I log into the server locally, so the client/server setup does not seem to be the cause of trouble. The only unusual thing about our setup I can think of is that the machines are located behind a firewall that blocks outgoing traffic -- if any of the plugins tried to communicate to the outside, it would get rejected. Following a discussion with Tim-Phlipp Müller on the gstreamer-devel list, I have produced the following diagnostics: - an strace of the ranaway gst-plugin-scanner process (see attachment) - the output of "GST_DEBUG=*:5 totem 2>dbg.log" (attached) - the output of cat "/proc/$PID/maps | grep gst" to see what plugins the process has open (attached). I also tried removing packages gstreamer-plugins-bad and gstreamer-plugins-ugly, but to no effect. The problematic plugin is not in there. One curious thing is, if I kill the runaway gst-plugin-scanner process, the player works fine -- and it also works fine for the next few times I call it. Until eventually it would hang again. This problem is severe in that it - renders all software using gstreamer unusable - pulls down the server by leaving a lot of runaway processes that use up 100% CPU I could not trace down the reason further. Any help is appreciated. Rüdiger
Created attachment 201403 [details] Ourput of "proc/$PID/maps | grep gst" for the runaway gst-plugin-scanner
Created attachment 201404 [details] Ourput of "GST_DEBUG=*:5 totem 2>dbg.log" spawning the runaway gst-plugin-scanner (gzipped)
I saw the same twice on my home machine maybe two weeks ago. Couldn't debug it since the machine became too unusable from heavy swapping. Is this on a 64-bit system?
Hi René, yes, this is a 64-bit system. Why do you ask?
Just collecting information. The issue is hard or impossible to reproduce it seems, so some guesswork might be needed :) My system is 64-bit as well, so this might be related (or not).
Okay. My latest suspicion is that it's related to the NVdida X driver. Do you have any NVidia drivers installed?
Actually I run NVidia's closed driver, yes. I wonder if that could be related; registry scanning should not depend on DISPLAY to begin with, so X should not be involved. How often does this happen for you?
It used to happen every time a started totem or banshee. The application would spawn gst-plugin-scanner which would not return, causing the application to hang. If I killed the gst-plugin-scanner process, the application would continue and work. It even worked after closing and reopening it -- for some time, then the same would happen again. The strange thing is that the problem does not appear any longer. (At the moment, at least.) It seems to have vanished at the time I removed package "nvidia-96", that's NVidias proprietary driver for legacy cards. Some of our clients run such cards, that's why we had it installed. Now NVidia's drivers do not co-exist well with other X drivers, basically, they replace a library with an NVidia specific version, breaking the other drivers. I did not notice that this was the case with our installation until recently. After I had removed "nvidia-96", I noticed that the runanway gst-plugin-scanner processes were gone. Of course, the two things could be completely unrelated. However, there is at least one other report that sound broke after installing NVidia drivers, here: http://sourceforge.net/mailarchive/forum.php?thread_name=CAJ6NrjEUDiP%2BdGJMugfVc-CBHyT1jPmHJVZJBjF_gPxzGas0YQ%40mail.gmail.com&forum_name=ltsp-discuss I do not know what to make of it either. It might be pure coincidence, but then I cannot think of anything else I have changed. Best, Rüdiger
As a data point, I've seen this a couple times on 64 bit Linux. The second time was when I was having two plugins with the same name though (when merging), so might have been due to this interacting badly with the registry. Very rare (for me).
Anybody being able to reproduce this with 1.0?
I have never had this problem again since I removed the nvidia-96 drivers. I still don't know if this was the cause of evil, though.
Let's close it for now then :) Not sure how that could be related to the nvidia drivers though