[Bug 664073] New: gst-plugin-scanner hangs, eating CPU time

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Mon Nov 14 13:43:34 PST 2011


https://bugzilla.gnome.org/show_bug.cgi?id=664073
  GStreamer | gst-plugins | 0.10.35

           Summary: gst-plugin-scanner hangs, eating CPU time
    Classification: Platform
           Product: GStreamer
           Version: 0.10.35
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: ruediger.kupper+bugzilla at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=201402)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=201402)
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

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.


More information about the gstreamer-bugs mailing list