Bug 71543 - [mesa] Source-based games segfault
Summary: [mesa] Source-based games segfault
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
Depends on:
Reported: 2013-11-12 18:44 UTC by Nikolay Amiantov
Modified: 2014-01-28 07:38 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:

bisect log (12.12 KB, text/plain)
2013-11-14 12:19 UTC, Nikolay Amiantov

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolay Amiantov 2013-11-12 18:44:29 UTC
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])
Comment 1 Nikolay Amiantov 2013-11-14 12:19:44 UTC
Created attachment 89188 [details]
bisect log

I've got some time, here's bisect log.
Comment 2 Nikolay Amiantov 2013-11-15 08:42:21 UTC
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 ()

That's quite strange, no Mesa calls at all, yet new Mesa definitely breaks things...
Comment 3 Nikolay Amiantov 2013-11-15 08:53:48 UTC
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.
Comment 4 Alexander Monakov 2013-11-15 10:13:34 UTC
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.
Comment 5 Nikolay Amiantov 2013-11-15 10:39:32 UTC
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?
Comment 6 Alexander Monakov 2013-11-15 15:27:11 UTC
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.
Comment 7 Nikolay Amiantov 2013-11-15 21:00:26 UTC
Thanks for the explanation, that looks like it. I've reported a bug to https://github.com/ValveSoftware/Source-1-Games/issues/1548
Comment 8 Nikolay Amiantov 2013-11-15 21:46:27 UTC
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.
Comment 9 Kenneth Graunke 2013-11-16 03:19:53 UTC
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...
Comment 10 Alexander Monakov 2014-01-21 13:19:47 UTC
*** Bug 73854 has been marked as a duplicate of this bug. ***
Comment 11 Benjamin Bellec 2014-01-21 20:09:06 UTC
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
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.
Comment 12 mmstickman 2014-01-21 20:16:31 UTC
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.
Comment 13 Alexander Monakov 2014-01-21 20:32:41 UTC
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).
Comment 14 Kenneth Graunke 2014-01-22 00:31:33 UTC
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.
Comment 15 Alexandre Demers 2014-01-26 13:30:47 UTC
(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
Comment 16 Fabio Pedretti 2014-01-28 07:38:58 UTC
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.