Launchpad has imported 24 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=66955.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2013-07-16T09:54:53+00:00 Philip Armstrong wrote: System: Radeon HD 5770, AMD Phenom II. Debian Linux kernel 3.9.8, mesa 9.1.4 libdrm-radeon 2.4.45 xserver-xorg-video-radeon 6.14.4 Running the Linux version of the game FTL causes the Xserver to segfault. The backtrace I get is: Backtrace: 0: /usr/bin/Xorg (xorg_backtrace+0x36) [0x7fba2ad6dd06] 1: /usr/bin/Xorg (0x7fba2abef000+0x182859) [0x7fba2ad71859] 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fba29f14000+0xf210) [0x7fba29f23210] 3: /usr/lib/x86_64-linux-gnu/dri/r600_dri.so (0x7fba256e5000+0x10c7a7) [0x7fba257f17a7] 4: /usr/lib/xorg/modules/extensions/libglx.so (0x7fba273a2000+0xddb1) [0x7fba273afdb1] 5: /usr/lib/xorg/modules/extensions/libglx.so (0x7fba273a2000+0x3c223) [0x7fba273de223] 6: /usr/bin/Xorg (0x7fba2abef000+0x52e61) [0x7fba2ac41e61] 7: /usr/bin/Xorg (0x7fba2abef000+0x41ec5) [0x7fba2ac30ec5] 8: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5) [0x7fba28b9f995] 9: /usr/bin/Xorg (0x7fba2abef000+0x4219d) [0x7fba2ac3119d] Segmentation fault at address 0x2d6a83b0 I'll see if I can get a better backtrace by installing the dbg packages. No errors appear in the dmesg output - this appears to be a userspace crash. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/0 ------------------------------------------------------------------------ On 2013-07-16T10:25:43+00:00 Philip Armstrong wrote: Turns out the real problem is that FTL bundles a version of libstdc++ that the DRI drivers won't link against. It looks like the net result is that *no* DRI drivers (not even swrast) can be loaded, and the Xserver dies when trying to invoke the first GLX call. Here's the output of the program with LIBGL_DEBUG=verbose : $ cat libgl_debug-output2.txt libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/r600_dri.so libGL error: dlopen /usr/lib/x86_64-linux-gnu/dri/r600_dri.so failed (/home/phil/games/FTL/data/amd64/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1)) libGL: OpenDriver: trying ${ORIGIN}/dri/tls/r600_dri.so libGL: OpenDriver: trying ${ORIGIN}/dri/r600_dri.so libGL error: dlopen ${ORIGIN}/dri/r600_dri.so failed (/home/phil/games/FTL/data/amd64/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1)) libGL: OpenDriver: trying /usr/lib/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib/dri/r600_dri.so libGL error: dlopen /usr/lib/dri/r600_dri.so failed (/usr/lib/dri/r600_dri.so: cannot open shared object file: No such file or directory) libGL error: unable to load driver: r600_dri.so libGL error: driver pointer missing libGL error: failed to load driver: r600 libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so libGL error: dlopen /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so failed (/home/phil/games/FTL/data/amd64/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1)) libGL: OpenDriver: trying ${ORIGIN}/dri/tls/swrast_dri.so libGL: OpenDriver: trying ${ORIGIN}/dri/swrast_dri.so libGL error: dlopen ${ORIGIN}/dri/swrast_dri.so failed (/home/phil/games/FTL/data/amd64/lib/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /usr/lib/x86_64-linux-gnu/libLLVM-3.2.so.1)) libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so libGL error: dlopen /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory) libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":3" after 10305 requests (10305 known processed) with 0 events remaining. If I remove the bundled libstdc++.so & use the system one then everything works as expected. Obviously this is still an Xorg crash bug though: the server ought not to crash if a userspace program fails to load a glx driver! Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/1 ------------------------------------------------------------------------ On 2013-07-16T10:26:21+00:00 Philip Armstrong wrote: Created attachment 82474 gdb backtrace of all threads Backtrace Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/2 ------------------------------------------------------------------------ On 2013-07-16T10:42:49+00:00 Philip Armstrong wrote: Created attachment 82475 Backtrace with dri symbols Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/3 ------------------------------------------------------------------------ On 2013-07-16T10:47:19+00:00 Philip Armstrong wrote: Changed title to reflect underlying bug: I don't believe that the user should be able to make the XServer process segfault by substituting the wrong libstdc++ library when running an ordinary user process. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/4 ------------------------------------------------------------------------ On 2013-07-16T13:17:51+00:00 Marek Olšák wrote: The solution is simple: don't use an older libstdc++. Lots of closed source apps do that, which breaks them if the Mesa driver was linked against a newer version. There is nothing we can do about that. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/5 ------------------------------------------------------------------------ On 2013-07-16T13:23:34+00:00 Marek Olšák wrote: Oh and by the way, the X crash seems to be caused by indirect rendering, which had been broken according to what Keith Packard said at XDC2012, IIRC. The issue will be trivially resolved by nuking indirect rendering if I understood Keith's plan correctly, leaving you with no rendering whatsoever and an even stronger incentive to delete the old libstdc++. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/6 ------------------------------------------------------------------------ On 2013-07-16T14:07:34+00:00 Philip Armstrong wrote: (In reply to comment #5) > The solution is simple: don't use an older libstdc++. Lots of closed source > apps do that, which breaks them if the Mesa driver was linked against a > newer version. There is nothing we can do about that. Obviously the solution is simple: I've already implemented it. But seriously? You think a hard Xserver crash caused by a userspace client is NotABug? I don't believe that it's reasonable for the Xserver to crash in this fashion: Refuse to run the application? Sure. Fall back to software rendering? Why not. Segfault and kill the entire desktop? That doesn't seem very user friendly to me frankly. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/7 ------------------------------------------------------------------------ On 2013-07-16T14:28:59+00:00 Marek Olšák wrote: Sorry for my hastiness. If you have a fix, that's great! Feel free to send it to the appropriate mailing list. Thanks! Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/8 ------------------------------------------------------------------------ On 2013-07-16T14:58:58+00:00 Philip Armstrong wrote: Sadly I was only referring to the 'dump the old libstdc++' solution to the immediate problem of the Xserver crashing. I don't have a patch at this point. If the reality is 'this problem is real, but will be going away in the next Xorg release because that rendering pipeline is going away' so it's a WONTFIX (or rather a WILLFIXINLATERRELEASE perhaps), then maybe that's ok. I do (personally) think crashing is always a bug however: the user shouldn't be able to crash the Xserver like this. (Segfaults smell of potential security issues too, even if in reality anyone with the level of access required to trigger this one can probably punch any number of holes in the system.) I'll take a look at the code and see what's going on, but if it turns out that the code in question is going away anyway then maybe it should be simply ripped out forthwith if it crashes like this? Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/9 ------------------------------------------------------------------------ On 2013-07-17T17:35:11+00:00 Idr wrote: Is the libstdc++ that the Xserver sees replaced? If the server is picking up the wrong libstdc++... yeah, don't do that. You wouldn't replace parts of your car engine with random parts from a different model, would you? :) If the driver loaded by the server is still using the correct system libstdc++, it should work fine. Two things to try: 1. Try running the app with LIBGL_ALWAYS_INDIRECT=y. Does it still crash the server? 2. Try collecting an apitrace of the application. You'll probably have to run it via ssh or from the console. Otherwise everything will be forcibly killed when the server dies, and you won't get a trace. It might be sketchy any way. Does replaying the trace on an unmangled system still crash the server? Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/10 ------------------------------------------------------------------------ On 2013-07-17T22:41:31+00:00 Philip Armstrong wrote: <i>Is the libstdc++ that the Xserver sees replaced? If the server is picking up the wrong libstdc++... yeah, don't do that. You wouldn't replace parts of your car engine with random parts from a different model, would you? :)</i> Nope, the Xserver is being linked against the system libstdc++ - it's being launched by gdm3 in a completely stock fashion. The only place the older libstdc++ is being used is when the binary in question is run: the shell script wrapper sets LD_LIBRARY_PATH to point to a directory of support libs, including the old libstdc++. I'm running it from a terminal which in turn is running on the desktop of the original Xsession launched by gdm3. If you look at the error messages from the program, it appears that the r600_dri.so (or any of the other mesa drivers) can't load as a result, because they're trying to link against the old libstdc++ (thanks to the LD_LIBRARY_PATH). I suspect the Xserver crashes because it tries to call into them anyway, despite the fact that the dlopen() call failed. I'll try the INDIRECT thing in the morning, if I get a chance. I doubt the API trace will kill the Xserver, because removing the old libstdc++ from the LD_LIBRARY_PATH of the binary works just fine, although I suppose the binary could be looking at GL features and changing it's behaviour depending on what's available: this is doubtful though as the openGL usage is very basic. It's just texture blits and scaling from watching the program in action. Can't hurt to try of course! Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/11 ------------------------------------------------------------------------ On 2013-07-17T22:44:28+00:00 Philip Armstrong wrote: NB. To put this another way, why is the Xserver letting a userspace program decide which libraries it should link it's own glx drivers against? Isn't that asking for trouble? Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/12 ------------------------------------------------------------------------ On 2013-07-17T22:57:14+00:00 Alan Coopersmith wrote: (In reply to comment #12) > NB. To put this another way, why is the Xserver letting a userspace program > decide which libraries it should link it's own glx drivers against? It shouldn't, unless that program is doing something like ldconfig to change the global linker configuration underneath the X server - the X server relies on the system loader & dlopen() to find its libraries. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/13 ------------------------------------------------------------------------ On 2013-07-17T23:07:33+00:00 Philip Armstrong wrote: Given that the program is being run as an ordinary unprivileged user, it shouldn't be playing games with ldconfig. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/14 ------------------------------------------------------------------------ On 2013-07-17T23:23:12+00:00 Idr wrote: (In reply to comment #14) > Given that the program is being run as an ordinary unprivileged user, it > shouldn't be playing games with ldconfig. It seems unlikely that it is, and that's why I've asked for those tests. Removing the actual application and the old libstdc++ from the equation (by using the apitrace with force indirect-rendering) will confirm whether or not this is a legit Xserver (or Mesa driver) bug or a system configuration issue. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/15 ------------------------------------------------------------------------ On 2013-07-18T06:55:24+00:00 Philip Armstrong wrote: So, running the Xserver as usual (ie, unchanged from stock install) & running FTL linked against the old libstdc++ but with LIBGL_ALWAYS_INDIRECT=y causes the Xserver to crash as before. I'm fairly sure that the setting is having an effect, because if I also set LIBGL_DEBUG=verbose, I don't get any extra output, whereas if I just set LIBGL_DEBUG & not LIBGL_ALWAYS_INDIRECT, I get the expected debugging output as seen above. I'm installing apitrace as I type. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/16 ------------------------------------------------------------------------ On 2013-07-18T08:02:23+00:00 Philip Armstrong wrote: Replaying the crashing trace recorded by apitrace does not cause the Xserver to crash, which seems unsurprising since everything is fine if the binary in question is linked against the system libstdc++ instead of the older bundled one. During the replay, we're recreating the latter situation, so it seems consistent that the Xserver is fine. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/17 ------------------------------------------------------------------------ On 2013-07-18T08:49:57+00:00 Michel-daenzer wrote: (In reply to comment #17) > Replaying the crashing trace recorded by apitrace does not cause the Xserver > to crash, [...] What if you replay it with LIBGL_ALWAYS_INDIRECT=y? I think this is just a normal indirect rendering bug, and libstdc++ only matters insofar as the bad one causes the app to fall back to indirect rendering. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/18 ------------------------------------------------------------------------ On 2013-07-18T09:19:08+00:00 Philip Armstrong wrote: Ah, I'd missed that case! Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/19 ------------------------------------------------------------------------ On 2013-07-18T09:29:29+00:00 Philip Armstrong wrote: (Hit post accidentally there) OK, so if I just set LIBGL_ALWAYS_INDIRECT, and link the binary against the usual system libraries, not the bundled ones (verified with ldd & running the binary directly, not via any shellscripts) then the Xserver crashes. Replaying the trace doesn't seem the trigger the crash though. It claims that the final call is 'incomplete' so perhaps I'm missing some crucial data? Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/20 ------------------------------------------------------------------------ On 2013-07-18T09:38:51+00:00 Philip Armstrong wrote: Running apitrace on the trace generated by running $ DISPLAY=:0.0 LIBGL_ALWAYS_INDIRECT=y apitrace trace ./amd64/bin/FTL from an ssh shell (which kills the Xserver) gives me the following output when I replay the trace: $ LIBGL_ALWAYS_INDIRECT=y apitrace replay FTL.trace apitrace: warning: caught signal 11 11813: error: caught an unhandled exception apitrace: info: taking default action for signal 11 but the Xserver remains live. The trace is 85Mb or so. Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/21 ------------------------------------------------------------------------ On 2013-07-18T09:41:01+00:00 Philip Armstrong wrote: tail of the trace dump is as follows: 11773 glGenTextures(n = 1, textures = &1870) 11774 glBindTexture(target = GL_TEXTURE_2D, texture = 1870) 11775 glTexImage2D(target = GL_TEXTURE_2D, level = 0, internalformat = GL_RGBA, width = 32, height = 32, border = 0, format = GL_RGBA, type = GL_UNSIGNED_BYTE, pixels = blob(4096)) 11776 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MIN_FILTER, param = GL_NEAREST) 11777 glTexParameterf(target = GL_TEXTURE_2D, pname = GL_TEXTURE_MAG_FILTER, param = GL_NEAREST) 11778 glGenLists(range = 256) = 1 11779 glGenTextures(n = 256, textures = ?) // incomplete Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/22 ------------------------------------------------------------------------ On 2013-07-18T09:46:20+00:00 Philip Armstrong wrote: Sorry: the mismatch in numbers is because the replay came from a different dump. Running it on the dump I posted gives the expected $ ~/Code/apitrace/build/apitrace replay FTL.trace apitrace: warning: caught signal 11 11779: error: caught an unhandled exception apitrace: info: taking default action for signal 11 Reply at: https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1221041/comments/23 ** Changed in: mesa Status: Unknown => Won't Fix ** Changed in: mesa Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu-X, which is subscribed to mesa in Ubuntu. https://bugs.launchpad.net/bugs/1221041 Title: Xorg crashed with SIGABRT in _mesa_GenTextures() To manage notifications about this bug go to: https://bugs.launchpad.net/mesa/+bug/1221041/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-x-swat Post to : ubuntu-x-swat@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-x-swat More help : https://help.launchpad.net/ListHelp
