GNOME Bugzilla – Bug 706836
cogl build hangs at GISCAN CoglPango-1.0.gir when building with wayland support
Last modified: 2013-10-22 17:56:05 UTC
Cogl now builds with wayland by default which causes the build to hang at GISCAN CoglPango-1.0.gir disabling wayland again fixes it (builds just fine).
Ok so my recollection of this is: g-ir-scanner needs to run a process at *build time* to extract data from it. Since cogl links to libGL.so, it pulls in the nVidia driver. The nvidia driver (as of only recently?) has an __attribute__ constructor which calls into libselinux to call is_selinux_enabled(). But libselinux.so *also* has an __attribute__ constructor which sets up internal state, and its public API assumes that state has been enabled. I think at a high level, no shared library can assume it can call anything other than libc from constructors. But libselinux could also be changed to be defensive about this. (Note libgobject.so also has a constructor, but I don't think that matters here).
In other words, someone needs to tell nVidia they can't do this, unless they get agreement from the libselinux people that it's OK. Why it only hangs in g-ir-scanner and apparently not on the final system I'm not sure.
Hrmm.. there's something fishy going on here. Cogl doesn't directly link against libGL and instead it dynamically opens it with g_module_open when you connect a renderer. Maybe something about introspecting cogl-pango causes it to create a renderer? That would explain why it presumably doesn't hang while scanning libcogl itself. The __attribute__ explanation doesn't seem like it could be the whole story because surely any application that links against libGL would have that same problem? Is there an easy way to attach gdb to the process that g-ir-scanner runs?
(In reply to comment #3) > Hrmm.. there's something fishy going on here. Cogl doesn't directly link > against libGL and instead it dynamically opens it with g_module_open when you > connect a renderer. Maybe something about introspecting cogl-pango causes it to > create a renderer? That would explain why it presumably doesn't hang while > scanning libcogl itself. > > The __attribute__ explanation doesn't seem like it could be the whole story > because surely any application that links against libGL would have that same > problem? > > Is there an easy way to attach gdb to the process that g-ir-scanner runs? Well the process hangs for a while so attaching gdb (at that point is easy). Here is the bt:
+ Trace 232422
(In reply to comment #4) > (In reply to comment #3) > > Hrmm.. there's something fishy going on here. Cogl doesn't directly link > > against libGL and instead it dynamically opens it with g_module_open when you > > connect a renderer. Maybe something about introspecting cogl-pango causes it to > > create a renderer? That would explain why it presumably doesn't hang while > > scanning libcogl itself. > > > > The __attribute__ explanation doesn't seem like it could be the whole story > > because surely any application that links against libGL would have that same > > problem? > > > > Is there an easy way to attach gdb to the process that g-ir-scanner runs? > > Well the process hangs for a while so attaching gdb (at that point is easy). s/for a while/forever/ and (gdb) bt
+ Trace 232423
Seems like it hangs in pthread_mutex_unlock / pthread_mutex_lock ...
I took this to the SELinux mailing list: http://marc.info/?l=selinux&m=137762578215857&w=2
I would just like to chime in and say I have noticed this same bug affecting an end system not using wayland. I use awesome on x and so far building gtk fails with a hang and certain processes in ibus-daemon and firefox hang forever. I attached gdb and got a similar backtrace to drago's.
There is an (internal) bug filed at NVIDIA's side on it: <aaronp> drago01, it calls into libselinux to query a bunch of stuff. I'll file a bug, but it might be tricky because I don't know whether there's any other time the GL can do that initialization. <aaronp> drago01, for reference, it's bug 1357836.
NVIDIA released a fixed (beta) driver today: "Deferred initialization of libselinux in the NVIDIA OpenGL driver, in order to avoid a problem where libselinux might not be ready when the NVIDIA libGL shared library is first loaded." I have tested the fix and it seems to work fine for me.