Bug 94512 - X segfaults with glx-tls enabled in a x32 environment
Summary: X segfaults with glx-tls enabled in a x32 environment
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: GLX (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium blocker
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-12 17:07 UTC by EoD
Modified: 2017-01-13 00:38 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
backtrace of the segfault (3.92 KB, text/plain)
2016-03-12 17:07 UTC, EoD
Details
LD_DEBUG=libs startx (28.06 KB, text/x-log)
2016-06-06 19:21 UTC, EoD
Details
x32 fix attempt (1.27 KB, patch)
2017-01-07 23:22 UTC, Grazvydas Ignotas
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description EoD 2016-03-12 17:07:46 UTC
Created attachment 122253 [details]
backtrace of the segfault

When I try launching X (via startx e.g.), X segfaults with the following backtrace.

The segfault does not happen when I use a software rasterizer.
Comment 1 Michel Dänzer 2016-03-15 02:19:32 UTC
Looks like maybe libglapi.so.0 should be picked up from somewhere other than /usr/libx32/libglapi.so.0? It should be from the same build as the rest of the Mesa binaries. If that's not the problem, please get a backtrace with debugging symbols available for /usr/libx32/libglapi.so.0 as well.
Comment 2 EoD 2016-03-18 22:32:33 UTC
(In reply to Michel Dänzer from comment #1)
> Looks like maybe libglapi.so.0 should be picked up from somewhere other than
> /usr/libx32/libglapi.so.0? It should be from the same build as the rest of
> the Mesa binaries. If that's not the problem, please get a backtrace with
> debugging symbols available for /usr/libx32/libglapi.so.0 as well.

I am not sure where it should be picked up from. How would I figure that out?

The library is from the same build as the rest of the Mesa binaries and the library has debugging symbols available.

/usr/libx32/libglapi.so:           symbolic link to libglapi.so.0.0.0
/usr/libx32/libglapi.so.0:         symbolic link to libglapi.so.0.0.0
/usr/libx32/libglapi.so.0.0.0:     ELF 32-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped
Comment 3 EoD 2016-03-19 11:37:08 UTC
This segfault is not restricted to starting X, but also happen with glxgears and glxinfo in a multilib environment.


I also figured out those segfaults only happen if glx-tls is enabled. If glx-tls is disabled X, glxinfo and glxgears work fine again.
Comment 4 Michel Dänzer 2016-03-22 03:54:44 UTC
Sounds like it's not a driver specific issue then but a general one with GLX-TLS on x32.
Comment 5 EoD 2016-03-22 22:11:48 UTC
(In reply to Michel Dänzer from comment #4)
> Sounds like it's not a driver specific issue then but a general one with
> GLX-TLS on x32.

X did not segfault when I used my Barts (radeon + r600) instead of the Tonga (amdgpu + radeonsi), although I had no acceleration on both. So there might be too issues here which I mixed up by accident. I'll stick to the glx-tls issue from now on.
Comment 6 Emil Velikov 2016-06-05 19:37:23 UTC
Based of the backtrace there is no information if mesa/libglapi was build with or w/o glx-tls. Following an IRC conversation it seems that the library is built w/o glx-tls as i is missing the _glapi_tls_Context and _glapi_tls_Dispatch symbols.

Perhaps they are different builds ? Either way it's good to attach the output of $nm -CD --defined-only /usr/libx32/libglapi.so in this particular case.

Also please that the correct libraries are being picked up. This can be done via something like:
 $LD_DEBUG=libs foo (startx) 2>ld_debug.log

Obviously none of these excludes that there is an actual issue with x32 and glx-tls and/or that mesa silently ignores the flag on said platform ;-)
Comment 7 EoD 2016-06-06 19:21:08 UTC
Created attachment 124376 [details]
LD_DEBUG=libs startx

(In reply to Emil Velikov from comment #6)
> Based of the backtrace there is no information if mesa/libglapi was build
> with or w/o glx-tls. Following an IRC conversation it seems that the library
> is built w/o glx-tls as i is missing the _glapi_tls_Context and
> _glapi_tls_Dispatch symbols.
> 
> Perhaps they are different builds ? Either way it's good to attach the
> output of $nm -CD --defined-only /usr/libx32/libglapi.so in this particular
> case.
> 
> Also please that the correct libraries are being picked up. This can be done
> via something like:
>  $LD_DEBUG=libs foo (startx) 2>ld_debug.log
> 
> Obviously none of these excludes that there is an actual issue with x32 and
> glx-tls and/or that mesa silently ignores the flag on said platform ;-)

glx-tls never worked for me on my x32 setup. This setup is only around half a year old, so I don't know if it worked before.

$ nm -CD --defined-only /usr/libx32/libglapi.so
00000004 B _glapi_tls_Context
00000000 D _glapi_tls_Dispatch
In full: https://gist.github.com/anonymous/543fd6a51163ced35819df49dbd0902c
Comment 8 Emil Velikov 2016-12-09 18:33:26 UTC
Double-checking the logs - seems like TLS is built/used throughout the board.
One thing which comes to mind - can you try with --disable-asm. I'm fairly sure that the code we have in there doesn't attribute x32.

Note: I'll be pushing a patch which makes --enable-glx-tls the default in a moment, so please keep it disabled locally until we get to the bottom of this.
Comment 9 EoD 2017-01-07 02:33:50 UTC
(In reply to Emil Velikov from comment #8)
> Double-checking the logs - seems like TLS is built/used throughout the board.
> One thing which comes to mind - can you try with --disable-asm. I'm fairly
> sure that the code we have in there doesn't attribute x32.
> 
> Note: I'll be pushing a patch which makes --enable-glx-tls the default in a
> moment, so please keep it disabled locally until we get to the bottom of
> this.

I can confirm that a "--enable-glx-tls --disable-asm" works as well as "--disable-glx-tls --enable-asm".
Comment 10 Grazvydas Ignotas 2017-01-07 23:22:51 UTC
Created attachment 128810 [details] [review]
x32 fix attempt

Maybe this patch will help?

If not, any tips how to set up a x32 environment without spending the whole day on it? My distro is Ubuntu.
Comment 11 Grazvydas Ignotas 2017-01-08 17:40:17 UTC
Ignore the previous patch, it's botched.
I've compiled the x32 deps, so could test what allowed to produce a working patch:
https://lists.freedesktop.org/archives/mesa-dev/2017-January/139946.html
Comment 12 EoD 2017-01-08 19:19:00 UTC
(In reply to Grazvydas Ignotas from comment #11)
> Ignore the previous patch, it's botched.
> I've compiled the x32 deps, so could test what allowed to produce a working
> patch:
> https://lists.freedesktop.org/archives/mesa-dev/2017-January/139946.html

I tried both patches and only the one on the ML is working.

I am no expert, but don't you want to use exact-length types instead of "long long"?
Comment 13 Grazvydas Ignotas 2017-01-08 21:04:38 UTC
(In reply to EoD from comment #12)
> I am no expert, but don't you want to use exact-length types instead of
> "long long"?

mapi doesn't use such types and I did not want to drag in a dependency. Also the modified file is for x86-64 only and has asm in GNU syntax, anything compiling that should have long long of 8 bytes.
Comment 14 Matt Turner 2017-01-13 00:38:26 UTC
Fixed by

commit 89458366585c34879b70110758bb4fd3acb62ce0
Author: Grazvydas Ignotas <notasas@gmail.com>
Date:   Sun Jan 8 19:38:09 2017 +0200

    mapi: update the asm code to support x32

Thanks Grazvydas!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.