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