Source games (Garry's Mod, Portal) segfault, with last good commit being 4e84f39 and last known bad ab2da98 (5442c0e is bad, too, mesa = libGL*, without radeon_dri) I don't have enough time at this week, so I can't bisect this now. Message: [ 1591.415826] gameoverlayui[15840]: segfault at 0 ip 00000000f6ff0fd9 sp 00000000ffbda850 error 4 in gameoverlayui.so[f6e6e000+712000] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Madison [Mobility Radeon HD 5650/5750 / 6530M/6550M] (prog-if 00 [VGA controller])
Created attachment 89188 [details] bisect log I've got some time, here's bisect log.
I've got stack trace: Program received signal SIGSEGV, Segmentation fault. 0x45b2e4a8 in udev_list_entry_get_next () from /usr/lib32/libudev.so.1 (gdb) bt #0 0x45b2e4a8 in udev_list_entry_get_next () from /usr/lib32/libudev.so.1 #1 0x45b33b8b in udev_monitor_filter_update () from /usr/lib32/libudev.so.1 #2 0xf788213e in udev_monitor_enable_receiving () from /home/abbradar/.steam/steam/SteamApps/common/GarrysMod/bin/libudev.so.0 #3 0xf795d7df in ?? () from /home/abbradar/.steam/steam/SteamApps/common/GarrysMod/bin/libSDL2-2.0.so.0 #4 0xf7948ae7 in ?? () from /home/abbradar/.steam/steam/SteamApps/common/GarrysMod/bin/libSDL2-2.0.so.0 #5 0xf78bf874 in SDL_InitSubSystem () from /home/abbradar/.steam/steam/SteamApps/common/GarrysMod/bin/libSDL2-2.0.so.0 #6 0xf789244f in ?? () from /home/abbradar/.local/share/Steam/SteamApps/common/GarrysMod/bin/inputsystem.so #7 0xf7890410 in ?? () from /home/abbradar/.local/share/Steam/SteamApps/common/GarrysMod/bin/inputsystem.so #8 0xf7f9bb36 in ?? () from bin/launcher.so #9 0xf7f9bc12 in ?? () from bin/launcher.so #10 0xf7f9be98 in ?? () from bin/launcher.so #11 0xf7f9beb0 in ?? () from bin/launcher.so #12 0xf7f83bbd in LauncherMain () from bin/launcher.so #13 0x080484d4 in main () (gdb) That's quite strange, no Mesa calls at all, yet new Mesa definitely breaks things...
I've just checked this on Intel (I have hybrid graphics) with same results. I don't really know where non card-specifin bugs should go, sending it to Mesa core... Oh, and I'm using x86_64 system with 32-bit libs for games.
As you can see in the backtrace, libudev.so.0 from Steam runtime calls into your system libudev.so.1. That definitely is not supposed to happen and can lead to a segfault.
Maybe I should post a bug to Valve, too, but with old revision of Mesa this do not happen. What else can I do to help identify cause of this?
As I understand new Mesa links against libudev while old Mesa did not. Therefore loading Mesa first brings in system libudev.so.1, and then libSDL2 pulls in libudev.so.0 from Steam runtime, but as libudev.so.0 is apparently not built with -Bsymbolic, some functions from libudev.so.0 are interposed by previously loaded libudev.so.1.
Thanks for the explanation, that looks like it. I've reported a bug to https://github.com/ValveSoftware/Source-1-Games/issues/1548
I've binary patched libudev.so.0 from Valse adding DT_SYMBOLIC to it, and indeed, it started! It doesn't work properly anyway, but this looks like a whole different story.
If Source games don't work out of the box and you have to resort to binary patching, then this is still a bug. I don't know which side will fix it, but...
*** Bug 73854 has been marked as a duplicate of this bug. ***
I confirm this bug (on RV770/r600g, Fedora 19 64-bit). In my case, it hits these games: - Half-Life - Half-Life² - Half-Life²: Episode One - Half-Life²: Episode Two - Counter Strike: Source but not: - Left 4 Dead 2 - Team Fortress 2 The first bad commit is: glx: use the loader util lib eac776cf779b705cbfb8d41812f1d171fb09c76f Signed-off-by: Emil Velikov I'm using this command to build mesa: ./autogen.sh --with-gallium-drivers=r600 --with-dri-drivers= --enable-texture-float --disable-dri3 --disable-r600-llvm-compiler --disable-gallium-llvm --enable-32-bit CFLAGS="-O2 -m32" CXXFLAGS="-O2 -m32" --libdir=/usr/lib I can also test with "nv50" if it's useful.
I can confirm that TF2 and L4D2 work fine, but I can add that none of the GoldSrc games work, and Day of Defeat: Source also doesn't work.
Thanks for providing the new bisect result. Yeah, it seems that that commit series greatly increase the visibility of the problem, since now libudev is linked in always, not just with --enable-dri3 (I think you still can pass --without-udev if you're building a sufficiently limited subset of Mesa, though).
Keith had a patch to drop the udev dependency from dri3, it's just sitting on the list waiting for review. Would need rebasing at this point. Not sure if Kristian's patch would impact this.
(In reply to comment #14) > Keith had a patch to drop the udev dependency from dri3, it's just sitting > on the list waiting for review. Would need rebasing at this point. Not > sure if Kristian's patch would impact this. For reference: http://lists.freedesktop.org/archives/mesa-dev/2014-January/052408.html
Fix pushed: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4556c734700da2dd95d4f148d6929a537882bade Reopen if needed.
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.