After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 769382 - qmlglsink: eglmemory memory leak on rpi
qmlglsink: eglmemory memory leak on rpi
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: 1.10.0
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-08-01 14:39 UTC by Sergey Borovkov
Modified: 2016-10-31 14:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sergey Borovkov 2016-08-01 14:39:02 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.
Comment 1 Tim-Philipp Müller 2016-08-06 16:12:10 UTC
Do you have a test pipeline or application that can be used to reproduce the leak you're seeing?
Comment 2 Sergey Borovkov 2016-08-06 17:47:35 UTC
I've been using decodebin -> queue -> qmlglsink. I will try to create test program if I am able to find time for that.
Comment 3 Sergey Borovkov 2016-10-18 08:24:36 UTC
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.
Comment 4 Matthew Waters (ystreet00) 2016-10-18 11:43:54 UTC
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