-
Notifications
You must be signed in to change notification settings - Fork 188
Description
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:
Lines 265 to 272 in 1b0b8e5
| // Poll the data as fast a spossible | |
| while(ros::ok()) | |
| { | |
| // This should block until a new frame is awake, this way, we'll run at the | |
| // actual capture framerate of the device. | |
| // ROS_DEBUG("Getting data..."); | |
| #if (GST_VERSION_MAJOR == 1) | |
| GstSample* sample = gst_app_sink_pull_sample(GST_APP_SINK(sink_)); |
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.