Memory leak under certain circumstances

[clover-es]

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: https://github.com/ros-drivers/gscam/blob/1b0b8e51b91522edadd8399d4ad920f8afbc487d/src/gscam.cpp#L265-L272

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.

[clover-es]

Also, this can be tested in a single terminal without the use of GSCam itself, running the following commands:

• Generates memory leak (nobody pulls the frames in the terminal, appsink element is not connected) gst-launch-0.10 v4l2src device=/dev/video0 ! video/x-raw-rgb,framerate=30/1 ! ffmpegcolorspace ! appsink

• Does NOT generate a memory leak (nobody pulls the frames in the terminal, appsink element is not connected, BUT only one frame is stuck the buffer) gst-launch-0.10 v4l2src device=/dev/video0 ! video/x-raw-rgb,framerate=30/1 ! ffmpegcolorspace ! appsink max-buffers=1

Max buffer value in the appsink element is set to 0 (unlimited) by default: https://gstreamer.freedesktop.org/documentation/applib/gstappsink.html?gi-language=c#gst_app_sink_set_max_buffers