[gstreamer-bugs] [Bug 636011] New: [mpegtsmux] leaks request pads

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Sun Nov 28 13:22:48 PST 2010


https://bugzilla.gnome.org/show_bug.cgi?id=636011
  GStreamer | gst-plugins-bad | git

           Summary: [mpegtsmux] leaks request pads
    Classification: Desktop
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: ds at schleef.org
         QAContact: gstreamer-bugs at lists.sourceforge.net
      GNOME target: ---
     GNOME version: ---


Private data on request pads don't get cleaned up when the element is
finalized.  This is mostly a reminder for myself to fix this when I have time.

Random notes, plus commentary on current events:

<ds> Should we be calling release_pad on each remaining request pad on
finalize()?
<MikeS-tp> ds: hey
<MikeS-tp> ds: in what? corea/
<MikeS-tp> ?
<MikeS-tp> err... core/
<MikeS-tp> goddammit. core?
<ds> well, core would be quite a change
<ohsix> theres mortars in north corea
<ds> ohsix:  can't we just unref() them and be done with it?
<ohsix> the new kid is a shitkicker :]
<MikeS-tp> ds: what were you talking about, then/
<ds> MikeS-tp: trying to clean up an element that releases resources in
release_pad().  But normal shutdown in gst-launch doesn't go through
release_pad for those pads.
<ds> so the choice is between a) having a separate cleanup mechanism for these
pads, or b) calling release_pad() in the core for each remaining request pad
<MikeS-tp> I don't see a good reason for normal element cleanup to not call
release_pad other than the difficulty of making it work backwards-compatibly
<MikeS-tp> I'd put it on the 0.11 list, and clean them up in gst-launch for
now?
<MikeS-tp> or if you want a totally non-invasive change, clean them up in the
element, but... this seems like something that should happen automatically
<ds> indeed
<MikeS-tp> by 'in gst-launch' I probably mean the parser code, which is...
never fun to hack on
<-- dnielsen_ has quit (Quit: Ex-Chat)
<ds> I don't think the parser code does anything special for teardown.
<ds> I'm probably going to go with the minimally invasive plan
<MikeS-tp> right, but it clearly _does_ need to do something special given the
current request pad semantics
<ds> right
<MikeS-tp> I guess that's a pain to do.
<MikeS-tp> but if you only do it in gst-launch.c, that means other things that
use the parser will leak

-- 
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