glGenFramebuffers fails when linked with OSMesa AND X11

[Peter Maersk-Moller]

Hi.

In latest update for Ubuntu Desktop 14.04.4 LTS, there is a serious problem when calling glGenFramebuffers() in a program that links both libOSMesa and libX11.

Attached is a test program that can verify this. If the program is compiled with the following

        gcc check_glgenframebuffer.c -lGL -lX11 -lOSMesa

then glGenFramebuffers() will fail when current context is set to GLX and the program will dump core upon exit. This is from gdb:

        Program received signal SIGSEGV, Segmentation fault.
        0x00007ffff2ef930e in ?? () from /usr/lib/x86_64-linux-gnu/dri/i965_dri.so

If the program is compiled with the following, then it works.

        gcc check_glgenframebuffer.c -lGL -lX11

This is a problem if you have a program that needs both libs such as the Open Source Video Mixer Snowmix.

Best regards
Peter Maersk-Moller

Installed libs:
ls -l /usr/lib/x86_64-linux-gnu/libOSMesa*
lrwxrwxrwx 1 root root 18 Jan 12 21:03 /usr/lib/x86_64-linux-gnu/libOSMesa.so -> libOSMesa.so.6.5.3
lrwxrwxrwx 1 root root 18 Jan 12 21:03 /usr/lib/x86_64-linux-gnu/libOSMesa.so.6 -> libOSMesa.so.6.5.3
-rw-r--r-- 1 root root 3708216 Jan 12 21:03 /usr/lib/x86_64-linux-gnu/libOSMesa.so.6.5.3

ls -l /usr/lib/x86_64-linux-gnu/libX11*
-rw-r--r-- 1 root root 2188236 Dec 4 2013 /usr/lib/x86_64-linux-gnu/libX11.a
lrwxrwxrwx 1 root root 15 Dec 4 2013 /usr/lib/x86_64-linux-gnu/libX11.so -> libX11.so.6.3.0
lrwxrwxrwx 1 root root 15 Dec 4 2013 /usr/lib/x86_64-linux-gnu/libX11.so.6 -> libX11.so.6.3.0
-rw-r--r-- 1 root root 1265072 Dec 4 2013 /usr/lib/x86_64-linux-gnu/libX11.so.6.3.0

ls -l /usr/lib/x86_64-linux-gnu/libGL.*
lrwxrwxrwx 1 root root 13 Jan 12 21:03 /usr/lib/x86_64-linux-gnu/libGL.so -> mesa/libGL.so

ls -l /usr/lib/x86_64-linux-gnu/mesa/*
-rw-r--r-- 1 root root 31 Jan 12 21:03 /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf
lrwxrwxrwx 1 root root 14 Jan 12 21:03 /usr/lib/x86_64-linux-gnu/mesa/libGL.so -> libGL.so.1.2.0
lrwxrwxrwx 1 root root 14 Jan 12 21:03 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1 -> libGL.so.1.2.0
-rw-r--r-- 1 root root 413968 Jan 12 21:03 /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0

ldd /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
 linux-vdso.so.1 => (0x00007ffe885cf000)
 libdrm_intel.so.1 => /usr/lib/x86_64-linux-gnu/libdrm_intel.so.1 (0x00007fdb85bac000)
 libdrm_nouveau.so.2 => /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.2 (0x00007fdb859a5000)
 libdrm_radeon.so.1 => /usr/lib/x86_64-linux-gnu/libdrm_radeon.so.1 (0x00007fdb85799000)
 libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007fdb8558c000)
 libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fdb85362000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdb85144000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdb84f40000)
 libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fdb84c3c000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdb84936000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdb84571000)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdb8435b000)
 libpciaccess.so.0 => /usr/lib/x86_64-linux-gnu/libpciaccess.so.0 (0x00007fdb84152000)
 /lib64/ld-linux-x86-64.so.2 (0x00007fdb8652a000)
 libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fdb83f39000)

ldd /usr/lib/x86_64-linux-gnu/libOSMesa.so
 linux-vdso.so.1 => (0x00007ffc773d0000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f3c1cdce000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f3c1cbca000)
 libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f3c1c8c6000)
 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f3c1c5c0000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3c1c1fb000)
 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f3c1bfe5000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f3c1d57f000)

ldd /usr/lib/x86_64-linux-gnu/libX11.so
 linux-vdso.so.1 => (0x00007ffe4328d000)
 libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f572a94c000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f572a748000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f572a383000)
 libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f572a17f000)
 libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f5729f79000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f572aea0000)

ldd /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1.2.0
 linux-vdso.so.1 => (0x00007ffc7f780000)
 libglapi.so.0 => /usr/lib/x86_64-linux-gnu/libglapi.so.0 (0x00007f19a4f61000)
 libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f19a4d4f000)
 libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 (0x00007f19a4b4c000)
 libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x00007f19a4946000)
 libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 (0x00007f19a4744000)
 libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f19a440f000)
 libxcb-glx.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-glx.so.0 (0x00007f19a41f8000)
 libxcb-dri2.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri2.so.0 (0x00007f19a3ff3000)
 libxcb-dri3.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0 (0x00007f19a3df0000)
 libxcb-present.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-present.so.0 (0x00007f19a3bed000)
 libxcb-sync.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-sync.so.1 (0x00007f19a39e7000)
 libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f19a37c8000)
 libxshmfence.so.1 => /usr/lib/x86_64-linux-gnu/libxshmfence.so.1 (0x00007f19a35c6000)
 libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x00007f19a33c0000)
 libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 (0x00007f19a31b3000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f19a2f95000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f19a2d91000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f19a29cc000)
 libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f19a27c8000)
 libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f19a25c2000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f19a53ee000)

Hardware:
  Lenovo Thinkpad T61
    Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (secondary) (rev 0c)

[Peter Maersk-Moller (pmaersk)]

Source for test program attached

[Peter Maersk-Moller (pmaersk)]

It should be noted that it worked in 14.04.03 LTS.

[Peter Maersk-Moller (pmaersk)]

The Bug has mistakenly been filed in 'Cairo'. Should be filed under OpenGL/GLX/OSMesa.

[Sebastien Bacher (seb128)]

Timo, did you ever got to look at that one?

[Timo Aaltonen (tjaalton)]

Have you tried on 15.10? There should be nothing special about the lts stack itself, DRI drivers and osmesa are built from the same source package.

[Timo Aaltonen (tjaalton)]

and the example works fine on 16.04

[Mike Miller (mtmiller)]

I think this bug is due to the change in the mesa package to build osmesa without using the shared glapi. I have seen similar errors using libosmesa6 10.1.3-0ubuntu0.6, when a program is linked with both libGL and libOSMesa. If the libosmesa6 packages are downgraded to 10.1.3-0ubuntu0.4, the errors disappear. Of course that version does not work when the mesa LTS HW enablement stack is used.

[Mike Miller (mtmiller)]

Just for completeness, since this bug report only mentions Ubuntu release numbers, the working version of libosmesa6 in 14.04.3 is 10.1.3-0ubuntu0.4, the version that fails in 14.04.4 is 10.1.3-0ubuntu0.6.

For my part, I am interested in how this affects Octave users because Octave links with both libGL for on-screen rendering and libOSMesa for off-screen rendering.

[Timo Aaltonen (tjaalton)]

and reverting -0ubuntu0.5 would then result in

https://bugs.launchpad.net/ubuntu/trusty/+source/mesa/+bug/1424059

again..

[Timo Aaltonen (tjaalton)]

what would fix these issues for good would be to let mesa roll forward unrenamed, that might actually happen for 16.04.x <fingerscrossed>

[Mike Miller (mtmiller)]

Right, so is there anything we can do to build OSMesa for 14.04.x users to resolve this? Or do we say sorry, don't mix OSMesa with OpenGL, hopefully it will be better in the next LTS? IOW do you see this moving towards "In Progress" or "Won't Fix"?

I completely understand the reasoning in bug #1424059, and maybe there is no other way to resolve this in trusty without apt/dpkg versioned Provides. I certainly don't have any ideas how to fix this.

[Timo Aaltonen (tjaalton)]

I don't see any other way than maybe stop building rest of mesa using shared glapi, but I don't know what that would break if anything

[Timo Aaltonen (tjaalton)]

mesa in 16.04 will get proper backports and not renamed like before, so this should not happen anymore.. sorry that there's no way to fix it in 14.04 lts