Memleak debugging

[Mathieu Duponchelle]

You're probably still leaking WebRTCBin itself :)

On Tue, 2022-09-06 at 14:40 +0200, Florian Echtler wrote:
> P.S. Seems my code is still leaking one each of the following objects
> per 
> connection: GstWebRTCDTLSTransport, GstWebRTCICEStream,
> GstWebRTCNiceTransport, 
> GstWebRTCSCTPTransport, GstSctpEnc, GstSctpDec, GstAppSink,
> GstAppSrc.
> 
> However, all of these are definitely created internally by WebRTCBin,
> so I can't 
> be holding any more references to them - suggestions for getting rid
> of them as 
> well?
> 
> Thanks again and best, Florian
> 
> On 06.09.22 13:07, Florian Echtler via gstreamer-devel wrote:
> > Oh wow, so obvious in hindsight 🤦
> > 
> > Thank you, I entirely forgot about the Python references. Seems to
> > work.
> > 
> > Best, Florian
> > 
> > On 06.09.22 11:14, Mathieu Duponchelle wrote:
> > > Hey Florian,
> > > 
> > > You need to make sure to release all references to elements, for
> > > instance clear self.mixers, self.outputs etc :)
> > > 
> > > Hope that helps
> > > 
> > > On Tue, 2022-09-06 at 08:39 +0200, Florian Echtler via gstreamer-
> > > devel
> > > wrote:
> > > > Hi everyone,
> > > > 
> > > > I noticed a resource leak in my Python-based WebRTC application
> > > > after
> > > > extended
> > > > runtime; it hangs with the repeated error message
> > > > "gst_poll_read_control:
> > > > assertion 'set != NULL' failed". AFAICT this likely means that
> > > > too
> > > > many GstBus
> > > > objects or bus watches are still hanging around.
> > > > 
> > > > I've taken care to cleanup all resources when a client
> > > > disconnects
> > > > and I've
> > > > verified this via the debug dot graph; there are no unexpected
> > > > elements or pads
> > > > hanging around anymore.
> > > > 
> > > > However, when I use the leak tracer, then it complains about a
> > > > huge
> > > > amount of
> > > > leaks, including all the elements I supposedly removed (e.g.
> > > > after 4
> > > > clients
> > > > have connected and disconnected, the leak tracer shows 4 leaked
> > > > GstWebRTCBin
> > > > objects).
> > > > 
> > > > Here's a snippet from the code I use to tidy up after a client
> > > > disconnects:
> > > > 
> > > >           # pause the bin
> > > >           self.wrb.bin.set_state(Gst.State.NULL)
> > > > 
> > > >           # pause, unlink, and remove the output buffers
> > > >           logging.debug("  Removing outputs...")
> > > >           for i in self.outputs:
> > > >               out_tee = self.outputs[i]
> > > >               out_tee.set_state(Gst.State.NULL)
> > > >               for p in out_tee.srcpads:
> > > >                   p.unlink(p.get_peer())
> > > >               remove_element(out_tee)
> > > > 
> > > >           # remove the bin
> > > >           logging.debug("  Removing main bin...")
> > > >           remove_element(self.wrb.bin)
> > > > 
> > > > AFAICT, if I stop and remove a bin, then it should deal with
> > > > its
> > > > internal
> > > > components on its own, correct? Is there something I'm missing?
> > > > I did
> > > > not use
> > > > blocking pad probes here because I don't care about buffers
> > > > getting
> > > > lost at this
> > > > point.
> > > > 
> > > > Any hints welcome!
> > > > 
> > > > For reference, the full code is here:
> > > > https://github.com/floe/surfacestreams/blob/main/client.py#L84-L140
> > > > 
> > > > Thanks and best, Florian
> > > > -- 
> > > > SENT FROM MY DEC VT50 TERMINAL
> > 
> > 
> 
> 
> -- 
> SENT FROM MY DEC VT50 TERMINAL