Memleak debugging

[Florian Echtler]

OK, found it: there was still a reference to the data channels and the WebSocket 
connection object. Now it's finally cleaned up properly.

Thanks again and best, Florian

On 06.09.22 15:01, Mathieu Duponchelle wrote:
> 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


-- 
SENT FROM MY DEC VT50 TERMINAL
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220907/0ddcb836/attachment.sig>