GNOME Bugzilla – Bug 769382
qmlglsink: eglmemory memory leak on rpi
Last modified: 2016-10-31 14:33:38 UTC
I am using qmlglsink on RPI. Using latest git master I noticed there were a lot of crashes in my application because of failure to create eglimage (running out of GPU memory). I have added some logging and according to it there were more allocations of eglimage compared to deallocations - I might have been wrong though. After reverting to older version (git commit cf7056a312e959643092ed31a0d8cfdffab6a8c6) everything is working without crashes. I had that commit + patch for eglmemory and patch for qmlglsink. So bug might have been introduced either there during the rework of that patch (https://bugzilla.gnome.org/show_bug.cgi?id=760916) or in git commit cf7056a312e959643092ed31a0d8cfdffab6a8c6 most likely. I was not able to point it to exactly what commit causes the issue unfortunately. It turned out to be painful because qmlglsink had to be patched as well because it was not working on RPI at that time. And trying git commit which just introduced eglmemory I was not able to get it working, I was getting some assertions in qmlglsink about negotiated being false. Please tell me if I can provide any additional useful information.
Do you have a test pipeline or application that can be used to reproduce the leak you're seeing?
I've been using decodebin -> queue -> qmlglsink. I will try to create test program if I am able to find time for that.
Just got to using this version of gstreamer again. What happens for me is the following. https://github.com/GStreamer/gst-plugins-bad/blob/25cb3afb58f8bc9c1f7134666f80d8173999a992/gst-libs/gst/gl/egl/gstglmemoryegl.c#L92 This gets called. Reference count of the image is before unref. But actual code that destroys eglimages never ends up getting called.
commit f5f4796b8f7adcd7dd59c6b281ed12d844b89ada Author: Matthew Waters <matthew@centricular.com> Date: Tue Oct 18 22:29:19 2016 +1100 gl/eglimage: Fix passing the destroy function to gst_egl_image_new_wrapped The function pointer and the user data arguments were swapped in both cases. https://bugzilla.gnome.org/show_bug.cgi?id=769382