I discovered a memory leak while using GSCam for a project. The problem is that, under certain circumstances, the GSCam node threat would run slower than the gstreamer pipeline and the frames will get stuck in the appsink given that nobody is pulling them at enough rate.

As I said, this is a strange combination that only occur under certain rare circumstances. In my case, this happened while running more than 2 instances of GSCam retrieving an uncompressed 4K image from capture devices (I guess the memory copy and conversion to ROS msg would take longer in this case, making the frames to get stuck in the appsink).

More specifically, the problem is seen in the following lines:

gst_app_sink_pull_sample() (and the following code) takes longer to execute than what GStreamer is taking to generate frames in the pipeline.

From GStreamer AppSink element documentation:

Appsink will internally use a queue to collect buffers from the streaming thread. If the application is not pulling samples fast enough, this queue will consume a lot of memory over time.