Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory leak under certain circumstances #63

Open
clover-es opened this issue May 25, 2020 · 1 comment · May be fixed by #64
Open

Memory leak under certain circumstances #63

clover-es opened this issue May 25, 2020 · 1 comment · May be fixed by #64

Comments

@clover-es
Copy link

clover-es commented May 25, 2020

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:

gscam/src/gscam.cpp

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.

@clover-es clover-es changed the title Memory leak under certain circunstances Memory leak under certain circumstances May 25, 2020
@clover-es
Copy link
Author

clover-es commented May 25, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant