Bug 952454

gdb glxinfo
r
bt

from the crash.

Also attach /var/log/Xorg.0.log

Created attachment 736564 [details]
gdb glxinfo

after install all debuginfos

Created attachment 736565 [details]
/var/log/Xorg.0.log

Wild guess, is there any rpath involved ?

Also I wonder why the intel glamor module is enforced from the config files.
Aren't xorg modules expected to be loaded automatically nowadays ?
"Loading /usr/lib64/xorg/modules/libglamoregl.so"

I have same problem, see this bug on rpmfusion bugzilla : https://bugzilla.rpmfusion.org/show_bug.cgi?id=2758

Particularly see comment 5 and 6.

(In reply to comment #6)
> I have same problem, see this bug on rpmfusion bugzilla :
> https://bugzilla.rpmfusion.org/show_bug.cgi?id=2758
> 
> Particularly see comment 5 and 6.

seems it is related with --enable-glx-tls in .spec

(In reply to comment #7)
...
> seems it is related with --enable-glx-tls in .spec
Can you reproduce with the affected version of mesa but without xorg-x11-glamor

is anyone seeing this without the binary driver? try reinstalling the binary driver maybe.

loading glamor explicitly is due to an interaction between glamor and glx load ordering, but nvidia glx shouldn't have any issues in theory.

(In reply to comment #9)

from http://pkgs.fedoraproject.org/cgit/mesa.git/commit/?id=3d536441811fefd2a7b35eebb8e3288a3f5e1b86
-BuildRequires: libtalloc-devel

why ?  what propose or could influence in segfault ?

(In reply to comment #8)
> (In reply to comment #7)
> ...
> > seems it is related with --enable-glx-tls in .spec
> Can you reproduce with the affected version of mesa but without
> xorg-x11-glamor

rpm -e xorg-x11-drv-ati.x86_64 xorg-x11-glamor.x86_64 --nodeps 

doesn't change glxinfo segfault ,

diff --git a/mesa.spec b/mesa.spec
index cdf5126..53fccb5 100644
--- a/mesa.spec
+++ b/mesa.spec
@@ -48,7 +48,7 @@
 Summary: Mesa graphics libraries
 Name: mesa
 Version: 9.1
-Release: 6%{?dist}
+Release: 8%{?dist}
 License: MIT
 Group: System Environment/Libraries
 URL: http://www.mesa3d.org
@@ -349,7 +349,6 @@ export CXXFLAGS="$RPM_OPT_FLAGS -fno-rtti -fno-exceptions"
     --enable-shared-glapi \
     --enable-gbm \
     --disable-opencl \
-    --enable-glx-tls \
 %if %{with_hardware}
     %{?with_vmware:--enable-xa} \
 %if 0%{?with_llvm}

fix this problem

libtalloc-devel isn't used in mesa anymore, --enable-glx-tls is an upstream configuration flag that we were meant to be using and require in order for ATI open source drivers to work properly. It won't be reverted.

I've no idea why the binary driver is choking here, reinstall its libGL and see do things still work.

I'm closing this as a Fedora bug unless someone can reproduce with no binary driver installed.

Maybe continue in the rpmfusion bug or talk to nvidia.

(In reply to comment #13)
> libtalloc-devel isn't used in mesa anymore, --enable-glx-tls is an upstream
> configuration flag that we were meant to be using and require in order for
> ATI open source drivers to work properly. It won't be reverted.
> 
> I've no idea why the binary driver is choking here, reinstall its libGL and
> see do things still work.
> 
> I'm closing this as a Fedora bug unless someone can reproduce with no binary
> driver installed.
> 
> Maybe continue in the rpmfusion bug or talk to nvidia.

You say it's not a bug, but : 

- for test I install mesa 9.1-6 on my Fedora 18 (with nvidia drivers installed), and I have same problem : direct rendering=  NO.

- that work fine with mesa 9.1-3.

So I think that the 9.1-6 version introduce this bug, and say it is not a bug is not very responsible.

That work before and don't work after.

If it's not a bug, what is it?

For the record, I'm not reproducing the issue with nvidia binary 304.88 on 32bit with geforce 7.

nVidia binary users, please discuss the issue here:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2758

(In reply to comment #14)

> 
> If it's not a bug, what is it?

Agree, at least you may close with a won't fix.

Created attachment 738338 [details]
Patch from openSuSE

I'm reopening this ticket as I've got more information about it and a patch which resolves it.

The problem is caused by the way the dynamic library loader decides which library it should use when there are multiple candidates. The latest mesa has changed the name which it exposes to the dynamic library loader. This change has caused the mesa libGL to have a higher preference than the nVidia libGL

With mesa-9.1-3.fc19:
$ ldconfig -p | grep libGL.so.1
	libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia/libGL.so.1
	libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1
	libGL.so.1 (libc6) => /usr/lib/nvidia/libGL.so.1
	libGL.so.1 (libc6) => /lib/libGL.so.1

With mesa-9.1-6.fc19:
$ ldconfig -p | grep libGL.so.1
	libGL.so.1 (libc6,x86-64, OS-ABI: Linux 2.4.20) => /lib64/libGL.so.1
	libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia/libGL.so.1
	libGL.so.1 (libc6) => /usr/lib/nvidia/libGL.so.1
	libGL.so.1 (libc6) => /lib/libGL.so.1

With the addition of the 'OS-ABI: Linux 2.4.20' label the mesa libGL always gets loaded instead of the nVidia libGL and causes breakage for environments where the nVidia driver is installed.

This issue was already reported in 2010 to upstream mesa and contains a patch to 'fix' the problem: https://bugs.freedesktop.org/show_bug.cgi?id=26663
The openSuSE folks also ran into this issue recently and updated the patch so it can be applied on the latest mesa: https://bugzilla.novell.com/show_bug.cgi?id=765294

I've attached the openSuSE patch to this ticket so you can consider applying it to the mesa package

Note that this only affects x86_64. i686 is not affected.

Same problem here, I actually thought it was a glibc bug as I've never had the chance to try mesa-9.1-3.fc19.

https://bugzilla.redhat.com/show_bug.cgi?id=951910

I'm closing the other bug down.

According to the changelog on kernel.org it has been released on 28th november 2002!... We get rid of much more recent stuff in Fedora....

According to freedesktop.org bug #26663 this seems pretty trivial.

Thanks,
--Simone

hi , 
Erik nice catch, thanks.
I confirm, this patch, on this report, fix glxinfo segfault.
I think fix on upstream, is a better solution ...

err I forgot renable-glx , I have to test it again , tomorrow, not today , big sorry :/ 
Comment #21 could be not corrected ...

For test I rebuild mesa 9.1-6 (with rpmbuild and mock) with OpenSuse patch, and --enable-glx-tls \ in mesa.spec, and for me that solve problem :

Direct rendering= YES

[dominique@host ~]$ ldconfig -p | grep libGL.so.1
        libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia/libGL.so.1
        libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib/nvidia/libGL.so.1
        libGL.so.1 (libc6) => /lib/libGL.so.1
[dominique@host ~]$

If that help you.

hi, 
OK works also here and also loads glamor
[    21.946] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
[    24.570] (II) Loading /usr/lib64/xorg/modules/nvidia-304xx-304.88/libglx.so
[    24.607] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so

(In reply to comment #24)
> hi, 
> OK works also here and also loads glamor
> [    21.946] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
> [    24.570] (II) Loading
> /usr/lib64/xorg/modules/nvidia-304xx-304.88/libglx.so
> [    24.607] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so

glamor is also load :
[     4.012] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so
[     4.096] (II) Loading /usr/lib64/nvidia/xorg/libglx.so
[     4.150] (II) Loading /usr/lib64/xorg/modules/drivers/nvidia_drv.so

Dominique , 
it is fixed upstream, 

in this patch 
http://cgit.freedesktop.org/mesa/mesa/patch/?id=904b03824b4c5cc24649aa69dd1a557ddfd5dda3

which means this patch can be add in Fedora before new upstream release. 

reference :
https://bugs.freedesktop.org/show_bug.cgi?id=26663 

Best regards,

(In reply to comment #26)
> Dominique , 
> it is fixed upstream, 
> 
> in this patch 
> http://cgit.freedesktop.org/mesa/mesa/patch/
> ?id=904b03824b4c5cc24649aa69dd1a557ddfd5dda3
> 
> which means this patch can be add in Fedora before new upstream release. 
> 
> reference :
> https://bugs.freedesktop.org/show_bug.cgi?id=26663 
> 
> Best regards,

OK...
For test I rebuild mesa with this patch, and it's good: 

[dominique@host ~]$ ldconfig -p | grep libGL.so.1
        libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia/libGL.so.1
        libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib/nvidia/libGL.so.1
        libGL.so.1 (libc6) => /lib/libGL.so.1

[dominique@host ~]$ ldconfig -p | grep libglamor
        libglamor.so.0 (libc6,x86-64) => /lib64/libglamor.so.0
        libglamor.so.0 (libc6) => /lib/libglamor.so.0

mesa-9.1.1-1.fc19 in update testing fix the bug for me :  

Direct rendering= YES

[dominique@host ~]$ ldconfig -p | grep libGL.so.1
        libGL.so.1 (libc6,x86-64) => /usr/lib64/nvidia/libGL.so.1
        libGL.so.1 (libc6,x86-64) => /lib64/libGL.so.1
        libGL.so.1 (libc6) => /usr/lib/nvidia/libGL.so.1
        libGL.so.1 (libc6) => /lib/libGL.so.1

[dominique@host ~]$ ldconfig -p | grep libglamor
        libglamor.so.0 (libc6,x86-64) => /lib64/libglamor.so.0
        libglamor.so.0 (libc6) => /lib/libglamor.so.0

mesa-9.1.1-1.fc19 has gone into the updates and the bug is fixed.

Thanks,
--Simone