* QA Notice: The following files contain executable stacks * Files with executable stacks will not work properly (or at all!) * on some architectures/operating systems. A bug should be filed * at http://bugs.gentoo.org/ to make sure the file is fixed. * For more information, see http://hardened.gentoo.org/gnu-stack.xml * Please include the following list of files in your report: * --- R-X RWX usr/lib/opengl/xorg-x11/lib/libGL.so.1.2 Reproducible: Always n22 ~ # emerge --info Portage 2.1.6.7 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.8_p20080602-r1, 2.6.27-gentoo-r10 i686) ================================================================= System uname: Linux-2.6.27-gentoo-r10-i686-Intel-R-_Pentium-R-_M_processor_1700MHz-with-glibc2.0 Timestamp of tree: Thu, 26 Mar 2009 16:15:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p39 dev-java/java-config: 2.1.7 dev-lang/python: 2.5.2-r7 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.4_p6, 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=pentium-m -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.muntinternet.net/pub/gentoo/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://mirror.muntinternet.net/pub/gentoo/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/" LDFLAGS="-Wl,-O1" LINGUAS="de en" MAKEOPTS="-j 2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="X aac acl acpi alsa apache2 berkdb bluetooth branding bzip2 cairo cdda cddb cdr cli cracklib crypt cups dbus dri dvd dvdr dvdread eds emboss encode evo exif fam fastbuild firefox fortran gdbm geoip gif gpm gstreamer gtk hyphenation iconv ipv6 isdnlog java jpeg kde kdeprefix libnotify mad mbox midi mikmod mmap mmx mmxext mp3 mp4 mpeg mudflap mysql ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pcre pdf perl png ppds pppd python qt3 qt3support qt4 quicktime readline reflection session spell spl sse sse2 ssl startup-notification svg sysfs tcpd tiff tk truetype unicode usb vorbis win32codecs wmf x86 xml xorg xpm xscreensaver xulrunner xv zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard evdev mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" USERLAND="GNU" VIDEO_CARDS="radeon" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Hardened, ccache and gcc 4.1. I have no idea what is causing this and if it is indeed a big deal. Feel free to send us (and upstream) patches to fix this. Thanks
*** Bug 264236 has been marked as a duplicate of this bug. ***
As said (and not said) in bug 264236, this happens too on x86, gcc 4.3.3, with following configure options: --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --with-driver=dri --enable-glx-tls --with-dri-drivers=,swrast,radeon,r200,r300 --disable-asm --enable-asm --disable-glut --without-demos --enable-xcb --disable-glw --disable-motif
(In reply to comment #3) > As said (and not said) in bug 264236, > this happens too on x86, gcc 4.3.3, Again, I don't know how to fix this. I don't even know what this is supposed to mean. I can't fix stuff I don't understand. Either file a bug in FreeDesktop's bugzilla or ask upstream why libGL is coded that way. Thanks
Actually, I don't understand it any more than you do. What's more, I think I misunderstood the message, or it was a false positive - if the *stack* was executable, 'X' would stand in the first group, as it does,i.e., here: RWX --- --- /usr/lib/libxvidcore.so.4.2 So, perhaps it's time to ask somebody, who actually knows this stuff.
reopening
@QA, we could use a hand here. I have no idea what's going on. If this is a false positive, feel free to close this. Thanks for any help
Rémi, the hardened project has some documentation on the matter at http://www.gentoo.org/proj/en/hardened/gnu-stack.xml ; it should be thorough enough.
Then my original comment still stands: patches are more than welcome as I don't have time to look into this. Thanks
Actually, it seems that doc doesn't cover this case.
Hm true, I sincerely thought it did; indeed the first group is stack and the other two should be relocation and probably the plt .. I'm trying to understand it but none of my chroots have this condition. Can you check which one of the object files is inducing this situation?
As I said in the other bug: 'scanelf -qeR .' on WORKDIR doesn't show anything besides the lib.
Terrific. Okay time to ask the big guns about this...
Hi there, I also encountered this yesterday. Glad to see it here. How this came up on my system: I had a fine running ~x86 system with mesa-7.3. Then I decided to upgrade to the x11-overlay. Everything works perfectly (xserver-1.6, KMS, DRI2, ...). glxgears (direct rendering: yes), tuxracer and compiz all run perfectly fine. But: If I try to use a self-compiled openGL-app, like: > #include <GL/gl.h> > #include <GL/glext.h> > #include <stdio.h> > > int main() { > glClear (GL_COLOR_BUFFER_BIT); //Clear the Color Buffer (more buffers later on) > return 0; > } and g++ -ggdb -lGL test.cpp -o test it fails executing (also fails without debugging/debugger) with > Program received signal SIGSEGV, Segmentation fault. > 0xb7ed30f6 in glClear () from //usr//lib/opengl/xorg-x11/lib/libGL.so.1 Ok, so yesterday, mesa-7.4 final reached the ~x86 tree and I upgraded. (so this is not an overlay-issue anymore). At the end of the mesa-7.4 compile process I noticed the * QA Notice: The following files contain executable stacks * <snip> * --- R-X RWX usr/lib/opengl/xorg-x11/lib/libGL.so.1.2 <snip> * QA Notice: Package has poor programming practices which may compile * fine but exhibit random runtime failures. I had this before with 7.4-rc1 but I didn't notice it. But now it's in ~x86 mesa-7.4 too and it bothers me as I can't run self-compiled openGL apps. I am _not_ using a hardened system. See my emerge --info below. But I nevertheless read the page (http://www.gentoo.org/proj/en/hardened/gnu-stack.xml) and it gave some little insights. Ok, this made it kind of 99% clear that this weird opengl segmentation faults have to come from this. I did some research on bugs.gentoo.org (this bugreport didn't exist yet) and found those 2 bugs, which are kind of old, but might be helpful: http://bugs.gentoo.org/show_bug.cgi?id=244661 http://bugs.gentoo.org/show_bug.cgi?id=240956 So I hope this is the right place for this. If I can do anything to help, I will gladly do, or if anyone knows how I can run my self-compiled openGL apps again. Hope this helps. emerge --info Portage 2.1.6.11 (default/linux/x86/2008.0, gcc-4.3.3, glibc-2.9_p20081201-r2, 2.6.29-gentoo i686) ================================================================= System uname: Linux-2.6.29-gentoo-i686-Intel-R-_Core-TM-2_Duo_CPU_L9400_@_1.86GHz-with-glibc2.0 Timestamp of tree: Mon, 30 Mar 2009 17:15:02 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p10-r1 dev-java/java-config: 2.1.7 dev-lang/python: 2.5.4-r2 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.2-r1 sys-apps/baselayout: 2.0.0 sys-apps/openrc: 0.4.3-r1 sys-apps/sandbox: 1.6 sys-devel/autoconf: 2.13, 2.63 sys-devel/automake: 1.5, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.19.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.28-r1 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=core2 -msse4.1 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=core2 -msse4.1 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache distlocks fixpackages metadata-transfer parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://mirror.switch.ch/ftp/mirror/gentoo" LANG="C" LDFLAGS="-Wl,-O1" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/x11" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X acl alsa automount avahi berkdb bluetooth bzip2 cdr cli cracklib crypt cups dbus dri dvd dvdr fam firefox fortran gdbm gif glitz gnome gnome-keyring gpm gtk hal iconv ipv6 isdnlog jpeg laptop midi mp3 mudflap ncurses networkmanager nls nptl nptlonly opengl openmp pam pcre perl png pppd python readline reflection samba session spl sse ssl svg sysfs tcpd tiff unicode x86 xcb xinerama xorg xulrunner xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse wacom vmmouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="intel vmware" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #14) But: If I try to use a self-compiled openGL-app, like: > > > #include <GL/gl.h> > > #include <GL/glext.h> > > #include <stdio.h> > > > > int main() { > > glClear (GL_COLOR_BUFFER_BIT); //Clear the Color Buffer (more buffers later on) > > return 0; > > } > > and g++ -ggdb -lGL test.cpp -o test > it fails executing (also fails without debugging/debugger) with > > > Program received signal SIGSEGV, Segmentation fault. > > 0xb7ed30f6 in glClear () from //usr//lib/opengl/xorg-x11/lib/libGL.so.1 Your program runs OpenGL commands without a properly initialized OpenGL context. I remember Mesa folks telling me once that doing this was undefined by the OpenGL spec, so they decided to make the program crash instead of pretending this is a valid call. If glxgears or more complex apps are working fine, then everything is fine. Thanks
Ok well, this test.cpp was just a simple example to demonstrate my case (which it looks it did wrong :-) ). I have a more complex openGL application that compiled and ran perfectly fine under mesa-7.3. This program now also produces the segfault when it reaches the first openGL command in the code. So unless my application initializes openGL wrong in the first case(I will check this later and try another example), but why did it work in mesa-7.3 then? Was it less error-sensitive? And why has mesa-7.4 suddenly this stack-etc. warning and this things actually worked before and don't anymore? So I think this segfaults in libGL and this QA warning really have to be connected... would be a very very big coincidence.
they may be related, but i doubt exec stacks cause crashes on a non-hardened system since the kernel will allow marked stacks to be executed can someone post a full build log as an attachment ? it might be something simple like a trampoline ... wonder if we should add a full scanelf log of the source tree in the exec case like we do with the textrel case ... that'd narrow down the objects that would have different exec markings
Created attachment 186807 [details] Build-log of mesa-7.4 with QA-error Well, here is my full /var/tmp/portage/media-libs/mesa-7.4/temp/build.log attached. I built it with: # FEATURES="-ccache noclean" emerge mesa -av These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/mesa-7.4 USE="nptl xcb -debug -doc -motif -pic" VIDEO_CARDS="intel -mach64 -mga -none -r128 -radeon -s3virge -savage -sis (-sunffb) -tdfx -trident -via" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] (Without -ccache the build took only 10 seconds as everything was still in the cache, so I hope this is right. Now it took a few minutes.) Just a quick note: I tried on my Ubuntu 8.10 with Mesa-7.2 (glxgears working perfectly there too!), and scanelf -lpqe shows "--- R-X RWX usr/lib/opengl/xorg-x11/lib/libGL.so.1.2" there too - and I also have the segfaults. I then tried an ancient GLUT-OpenGL demo (tutorial02 from nehe-gamedev) and it works without a segfault... But on my "old" Mesa-7.3 gentoo it worked perfectly. Also on Fedora... So this is really strange... Would be nice to know, if Mesa-7.3 also has that "executable Stack"-thingy. Maybe I can try and downgrade tomorrow (well, don't know if that will brake Xorg... :-) )
Ok, I just did: # emerge =mesa-7.3 -av -There was no QA-Warning or executable-stack-message of any kind. -All my compiled applications work fine again without segfaults (even my test.cpp posted above works). -"scanelf -lpqe" doesn't list libGL.so at all anymore. So I guess something really has to be broken :\
(In reply to comment #19) > Ok, I just did: # emerge =mesa-7.3 -av > > -There was no QA-Warning or executable-stack-message of any kind. > > -All my compiled applications work fine again without segfaults (even my > test.cpp posted above works). > > -"scanelf -lpqe" doesn't list libGL.so at all anymore. > > So I guess something really has to be broken :\ I guess git bisecting mesa should tell us which commit broke this. The history between 7.3 and 7.4 is pretty linear and a bisect should take a dozen rebuilds at most. It'd be very helpful if you could do that. Thanks
the problem isn't executable stacks but an RWE PT_LOAD segment which is what the TLS gl dispatcher requires and it cannot be fixed, it's by design. in some related bug i wrote about it already btw, also about the sparc/asm enable snafu which is apparently still not fixed in the ebuild.
you're right of course ... the output clearly shows this :) STK/REL/PTL --- R-X RWX i thought our previous complaints against the GL stack was textrels, not writable PT_LOADs ...
(In reply to comment #22) > i thought our previous complaints against the GL stack was textrels, not > writable PT_LOADs ... it was always about (unnecessary) runtime code generation, but since then the turn of events made it clear that such features of mesa are here to stay. even with the C dispatcher where this RWE PT_LOAD goes away (that is, once someone pretty please fixes the pic/sparc USE crap) we'll have the problem with the tnl engine (as i described it in another bug). in any case, i'm not sure what this bug is about here, looks like two separate issues. one is the RWE PT_LOAD, which we can't fix (beyond the pic/sparc stuff). the other is an apparent crash somewhere that IMHO cannot be caused by the RWE PT_LOAD per se, so it needs more debugging, a core analysis would be a first step or some (valid) app that anyone can compile and reproduce the crash with.
What is really striking me though is why this whole mesa stack/PT_LOAD/asm whatever-it-is issue seems to be kind of "fixed" and working very well with mesa-7.3, but in mesa-7.4 it does not anymore. So this kind of seems like there is actually something that could be done to "make the behaviour of mesa better" (as gentoo did with mesa-7.3, and some other distributions do). (@Pax-Team, yes the second 'problem' is with my custom code but I think it's directly related to this issue . But as regular opengl apps work, you can of course always say "it's your code, fix your setup", and that's of course true and what I will also try to do. But the fact stands, that my code only fails with mesa-versions that have this "--- R-X RWX", and it works on any other regular mesa-version (like 7.3).) But thank you all for your help so far, if there is anything more I can do, I will try :-)
Well, you could take the "old" but busted mesa 7.3 ebuild and rename it to 7.4 to see if that helps. Or you could also run a git-assisted manual bisect between 7.3 and 7.4 to see which commit triggered the QA warning. Thanks
*** This bug has been marked as a duplicate of bug 240956 ***
