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 783776 - gsteglimage: eglDestroyImage is used for images created by eglCreateImageKHR
gsteglimage: eglDestroyImage is used for images created by eglCreateImageKHR
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.12.0
Other Linux
: Normal critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-06-14 04:52 UTC by Yuji Kuwabara
Modified: 2017-06-14 08:28 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Yuji Kuwabara 2017-06-14 04:52:43 UTC
On RaspberryPi3 (RASPBIAN JESSIE), without EGL_VERSION_1_5 macro, _gst_egl_image_create() uses eglCreateImageKHR() .
But _gst_egl_image_destroy() uses eglDestroyImage() if it is available.
Broadcom VideoCore library EGL provide valid function address of eglDestroyImage(), but it is not same as eglDestroyImageKHR().
eglDestroyImage() always fails and a debug message "eglDestroyImage failed" is output.
Thus memory leak.
If eglDestroyImageKHR() is used, it succeeds.

How to reproduce:
> export GST_DEBUG=2
> gst-launch-1.0 filesrc location=<videofile> ! decodebin ! glimagesink
   :
   :
0:01:53.499545048  2300  0x1a27520 WARN              gleglimage gsteglimage.c:295:_gst_egl_image_destroy:<glcontextegl0> eglDestroyImage failed
0:01:53.506686259  2300  0x1a27520 WARN              gleglimage gsteglimage.c:295:_gst_egl_image_destroy:<glcontextegl0> eglDestroyImage failed
0:01:53.507043497  2300  0x1a27520 WARN              gleglimage gsteglimage.c:295:_gst_egl_image_destroy:<glcontextegl0> eglDestroyImage failed
0:01:53.507303860  2300  0x1a27520 WARN              gleglimage gsteglimage.c:295:_gst_egl_image_destroy:<glcontextegl0> eglDestroyImage failed
0:01:53.507561046  2300  0x1a27520 WARN              gleglimage gsteglimage.c:295:_gst_egl_image_destroy:<glcontextegl0> eglDestroyImage failed
Setting pipeline to NULL ...
Freeing pipeline ...
Comment 1 Yuji Kuwabara 2017-06-14 07:17:14 UTC
Sorry, I need a correction.

gst_gl_context_default_get_proc_address() returns address of eglDestroyImage() from /usr/lib/arm-linux-gnueabihf/libEGL.so.1
(not VideoCore library)

gst_gl_context_default_get_proc_address() returns address of eglCreateImageKHR() from /opt/vc/lib/libEGL.so (intended).
Comment 2 Sebastian Dröge (slomo) 2017-06-14 07:24:11 UTC
That means you've compiled gst-plugins-bad wrong and/or your shared library path configuration is broken. When compiling gst-plugins-bad on the RPi, you probably want to pass --with-egl-module-name=/opt/vc/lib/libEGL.so to configure (also check the other --with-XXX-module-name).

It also would make sense to get rid of the non-Broadcom GL/GLES/EGL/etc libraries on your system to prevent any conflicts in the future.


Does that solve your problem?
Comment 3 Yuji Kuwabara 2017-06-14 07:38:31 UTC
Yes, I renamed /usr/lib/arm-linux-gnueabihf/libEGL.so.1 to libEGL_.so.1 .
It solved the problem.

I also tried to modify "gst-libs/gst/gl/egl/gsteglimage.c"
(leaving /usr/lib/arm-linux-gnueabihf/libEGL.so.1 as is)
It also solved the problem. (I think this is more consistent with _gst_egl_image_create()
--------------------------------------------------------------------
_gst_egl_image_destroy (GstGLContext * context, EGLImageKHR image)
{

#ifdef EGL_VERSION_1_5
  gst_eglDestroyImage = gst_gl_context_get_proc_address (context,
      "eglDestroyImage");
  if (!gst_eglDestroyImage)
#endif
  {
--------------------------------------------------------------------
Comment 4 Matthew Waters (ystreet00) 2017-06-14 08:17:19 UTC
If you ever have a case where two different libEGL libraries are being loaded, you've configured gst-plugins-bad incorrectly and that is completely unsupported.  You need to configure gst-plugins-bad to not load two different libEGL libraries.
Comment 5 Yuji Kuwabara 2017-06-14 08:28:53 UTC
Thank you , I understand my problem.