GNOME Bugzilla – Bug 739688
Crash when using glimagesink
Last modified: 2016-02-24 10:33:02 UTC
Created attachment 290053 [details] gdb backtrace for all threads I get a crash under 1.4.3 when I run: gst-launch-1.0 playbin uri=http://dvb:4242/bysid/4352 video-sink="glimagesink" This only happens when I use glimagesink. A gdb backtrace for all threads is attached. Issue created in response to a request from Matthew Waters on the GStreamer development mailing list.
Created attachment 290054 [details] GST_DEBUG=gl*:8,default:7 log file related to the crash
Created attachment 290055 [details] GST_DEBUG=gl*:7,default:7 log file related to the crash
gstglcontext.c:612:_create_context_info: GL_VERSION: (NULL) gstglcontext.c:614:_create_context_info: GL_SHADING_LANGUAGE_VERSION: (NULL) gstglcontext.c:616:_create_context_info: GL_VENDOR: (NULL) gstglcontext.c:618:_create_context_info: GL_RENDERER: (NULL) You don't seem to have GL available or gstgl doesn't know your platform. What's the platform you're developing on?
It's a platform built using Yocto Project and has GLES2 support provided by the Intel PVR driver for Cedartrail. Everything is built from source. I have a GLES application (with GStreamer) working using EGL under X on this platform and it is here that I hope to be able to use the gl plugins. Could this just be down to me needing to provide some "magic" at build time?
It seems from closer inspection of the log that the GL function retrieval seems to be failing. This would require further debugging to figure out why it's failing with your setup. You'd need to step through the gst_gl_context_get_proc_address() or gst_gl_context_default_get_proc_address() function in order to figure out what is failing where.
I recently hit this issue (or so I thought) on a Raspberry Pi. It's probably worth checking to ensure that you're not actually loading two different GL libraries - I was /opt/vc/lib/libGLESv2.so (Broadcom VideoCore) and then GStreamer was later pulling in /usr/lib/libGLESv2.so (Mesa). Just a thought.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!
As Luke-Granger-Brown says, the glimagesink also crashes on my Raspberry Pi 2 Model B. How to resolve two different GL libraries?
Created attachment 322002 [details] gdb backtrace on Raspberry Pi 2 Model B System: Raspberry Pi 2 Model B RASPBIAN JESSIE Linux 4.1.17-v7+
Reopening for further investigation
*** Bug 762551 has been marked as a duplicate of this bug. ***
It would be good if someone retried this with either git master (1.7.x) or 1.6.x. A lot of changes have happened since 1.4, I don't think anyone is going to debug 1.4 code any more :)
The rpi's problem is that there can be multiple GL libraries. The /opt/vc/lib ones and the mesa ones. The /opt/vc/libs ones aren't quite setup correctly. To check if you're loading both GL implementations, perform an info sharedlibrary command in gdb when it crashes. There should only be one entry for libEGL.so and libGLESv2.so. You have two options to fix. 1. configure gst-plugins-bad with --with-gles2-module-name and --with-egl-module-name pointing to the /opt/vc/lib libraries. 2. create symlinks in a directory from libGLESv2.so.2 to /opt/vc/lib/libGLESv2.so and from libEGL.so.1 to /opt/vc/lib/libEGL.so and point LD_LIBRARY_PATH to your symlink directory.
I performed the info sharedlibrary command in gdb and added the output to the attachments. I think the problem is because there are /opt/vc/lib/libEGL.so /opt/vc/lib/libGLESv2.so and /usr/lib/arm-linux-gnueabihf/libEGL.so.1 /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 right? @Matthew Waters: Why creating symlinks to the /opt/vc/lib ones when you said that "The /opt/vc/libs ones aren't quite setup correctly."?
Created attachment 322207 [details] gdb info sharedlibrary command
Because we look for libEGL.so.1 and libGLESv2.so.2 (as is the de facto standard when looking up versioned libraries because the .so files are in the -dev{el} packages) which don't exist in /opt/vc/lib
Thank you very much. I created symlinks to the /opt/vc/lib ones and the glimagesink does not crash anymore. For the ones who find this while googling this fixed the problem for me: $ sudo ln -s -f /opt/vc/lib/libGLESv2.so /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2 $ sudo ln -s -f /opt/vc/lib/libEGL.so /usr/lib/arm-linux-gnueabihf/libEGL.so.1
And do not forget to remove the old links of course ...
The original issue on the Intel PVR system is still missing details.