I see that now, all Source games segfault as well.

This happens on all of my systems: a Radeon HD 4650 laptop, Radeon HD 6850 desktop, and Radeon HD 7950 desktop.

Can you bisect?

Please provide a backtrace for the segfault.

Half-Life (GoldSrc):
#0  0x4ccc63c8 in udev_list_entry_get_next () from /lib/libudev.so.1
#1  0x4cccb9db in udev_monitor_filter_update () from /lib/libudev.so.1
#2  0xf063c13e in udev_monitor_enable_receiving () from /home/nicholas/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libudev.so.0
#3  0xf48fc4bf in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life/libSDL2-2.0.so.0
#4  0xf48e7817 in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life/libSDL2-2.0.so.0
#5  0xf485e874 in SDL_InitSubSystem () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life/libSDL2-2.0.so.0
#6  0xf4b9ab63 in CGame::CreateGameWindow (this=0xf52ee6e0 <g_Game>) at ../engine/sys_sdlwind.cpp:761
#7  0xf4b9a6fc in Init (pvInstance=<optimized out>, this=0xa02ced8) at ../engine/sys_getmodes.cpp:338
#8  CVideoMode_OpenGL::Init (this=0xa02ced8, pvInstance=0x0) at ../engine/sys_getmodes.cpp:1587
#9  0xf4ad203a in RunListenServer (instance=0x0, basedir=0x804b220 <szBaseDir> "/home/nicholas/.local/share/Steam/SteamApps/common/Half-Life", 
    cmdline=0x9e86548 "/home/nicholas/.local/share/Steam/SteamApps/common/Half-Life/hl_linux -steam", 
    postRestartCmdLineArgs=0x804d360 <main::szNewCommandParams> "", launcherFactory=0x8049350 <CreateInterfaceLocal(char const*, int*)>, filesystemFactory=
    0xf7694ad0 <CreateInterface(char const*, int*)>) at ../engine/sys_dll2.cpp:916
#10 0x08048d67 in main (argc=2, argv=0xffe1c9a4) at ../launcher/launcher.cpp:439

Half-Life 2 (Source):
#0  0x4ccc63c8 in udev_list_entry_get_next () from /lib/libudev.so.1
#1  0x4cccb9db in udev_monitor_filter_update () from /lib/libudev.so.1
#2  0xed1d713e in udev_monitor_enable_receiving () from /home/nicholas/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libudev.so.0
#3  0xf5a5d761 in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life 2/bin/libSDL2-2.0.so.0
#4  0xf59e68be in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life 2/bin/libSDL2-2.0.so.0
#5  0xf59b8f25 in SDL_InitSubSystem () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life 2/bin/libSDL2-2.0.so.0
#6  0xf168c802 in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life 2/bin/inputsystem.so
#7  0xf168a650 in ?? () from /home/nicholas/.local/share/Steam/SteamApps/common/Half-Life 2/bin/inputsystem.so
#8  0xf60bf826 in ?? () from bin/launcher.so
#9  0xf60bf902 in ?? () from bin/launcher.so
#10 0xf60bfb88 in ?? () from bin/launcher.so
#11 0xf60bfba0 in ?? () from bin/launcher.so
#12 0xf60a7d95 in LauncherMain () from bin/launcher.so
#13 0x08048504 in main ()

Did Mesa gain an udev dependency recently?

For me CounterStrike 1.6 works fine using 10.1.0-devel (git-ded5674), this is with Intel Haswell and Ubuntu 12.04, I believe this game is using GoldSrc engine. I also tried HL2 with Ivybridge + mesa master and it worked fine. Not sure how to track libudev version (which is used), steam-runtime has its own copy of libudev so maybe it causes some conflict in your system?

(In reply to comment #6)
> For me CounterStrike 1.6 works fine using 10.1.0-devel (git-ded5674), this
> is with Intel Haswell and Ubuntu 12.04, I believe this game is using GoldSrc
> engine. I also tried HL2 with Ivybridge + mesa master and it worked fine.
> Not sure how to track libudev version (which is used), steam-runtime has its
> own copy of libudev so maybe it causes some conflict in your system?

Do you have any AMD GPUs to test with your system? I've been hearing a lot of people having the same issue I am, but they all seem to have AMD GPUs.

The problem is simultaneous loading of multiple libudev.so's; see https://bugs.freedesktop.org/show_bug.cgi?id=71543 and http://lists.freedesktop.org/archives/mesa-dev/2013-November/048566.html (patch still not committed as far as I can see)

*** This bug has been marked as a duplicate of bug 71543 ***

(In reply to comment #8)
> The problem is simultaneous loading of multiple libudev.so's; see
> https://bugs.freedesktop.org/show_bug.cgi?id=71543 and
> http://lists.freedesktop.org/archives/mesa-dev/2013-November/048566.html
> (patch still not committed as far as I can see)
> 
> *** This bug has been marked as a duplicate of bug 71543 ***

Are you sure about that? This bug only started happening yesterday.

(In reply to comment #7)
> Do you have any AMD GPUs to test with your system? I've been hearing a lot
> of people having the same issue I am, but they all seem to have AMD GPUs.

cstrike 1.6 does work here with r600g (radeon hd 5770).

(In reply to comment #9)
> (In reply to comment #8)
> > The problem is simultaneous loading of multiple libudev.so's; see
> > https://bugs.freedesktop.org/show_bug.cgi?id=71543 and
> > http://lists.freedesktop.org/archives/mesa-dev/2013-November/048566.html
> > (patch still not committed as far as I can see)
> > 
> > *** This bug has been marked as a duplicate of bug 71543 ***
> 
> Are you sure about that? This bug only started happening yesterday.

Please run git-bisect to pinpoint what git commit changed things, then.

I have no experience running git bisects, let alone compiling all of mesa and xorg drivers. I am just an Ubuntu user that uses the Oibaf PPA which keeps up to date with the latest git of mesa/xorg daily. Several others in the thread have mentioned the problem since yesterday: http://phoronix.com/forums/showthread.php?50038-Updated-and-Optimized-Ubuntu-Free-Graphics-Drivers/page93

Here is the changelist of the ppa build: https://launchpadlibrarian.net/162987663/mesa_10.1~git1401210730.ded567+curaga~gd~s_source.changes

And here is the corresponding Mesa commit list: http://cgit.freedesktop.org/mesa/mesa/log/?qt=range&q=d6b6ab5..ded5674 .  Mostly ARB_viewport_array and i965 changes; I see no udev-related changes, or radeon-related changes.

It might be that mmstickman and Nicholas Miell are seeing different segfaults, in which case: mmstickman, please provide the backtrace.  IIRC you can run "GAME_DEBUGGER=gdb steam" in terminal, launch the game, then type "r" in the gdb prompt to start the game, and "bt" to obtain the backtrace after it segfaulted.

(In reply to comment #13)
> Here is the changelist of the ppa build:
> https://launchpadlibrarian.net/162987663/mesa_10.1~git1401210730.
> ded567+curaga~gd~s_source.changes
> 
> And here is the corresponding Mesa commit list:
> http://cgit.freedesktop.org/mesa/mesa/log/?qt=range&q=d6b6ab5..ded5674 . 
> Mostly ARB_viewport_array and i965 changes; I see no udev-related changes,
> or radeon-related changes.
> 
> It might be that mmstickman and Nicholas Miell are seeing different
> segfaults, in which case: mmstickman, please provide the backtrace.  IIRC
> you can run "GAME_DEBUGGER=gdb steam" in terminal, launch the game, then
> type "r" in the gdb prompt to start the game, and "bt" to obtain the
> backtrace after it segfaulted.

That doesn't seem to do anything. The game launches without needing to issue r and bt subsequently does nothing.

(In reply to comment #9)
> (In reply to comment #8)
> > The problem is simultaneous loading of multiple libudev.so's; see
> > https://bugs.freedesktop.org/show_bug.cgi?id=71543 and
> > http://lists.freedesktop.org/archives/mesa-dev/2013-November/048566.html
> > (patch still not committed as far as I can see)
> > 
> > *** This bug has been marked as a duplicate of bug 71543 ***
> 
> Are you sure about that? This bug only started happening yesterday.

It's pretty obvious from the backtrace that it's the same issue.  Note that the bug is only exhibited in mesa with dri3 support enabled.  It's possible that your most recent update enabled dri3 support while previous versions had it disabled.

(In reply to comment #15)
> It's pretty obvious from the backtrace that it's the same issue.  Note that
> the bug is only exhibited in mesa with dri3 support enabled.  It's possible
> that your most recent update enabled dri3 support while previous versions
> had it disabled.

Hm, if you look at the changes file, or peruse the build log from the aforementioned PPA, you will find that DRI3 was disabled all the time.  So it must be something else.

Benjamin Bellec provided the bisect result in bug 71543.  It's the same problem, but it got more visibility (not limited to --enable-dri3 now) due to a recent commit.  Let's continue in that (still open) bugreport?

Created attachment 92554 [details] [review]
glx: link loader when building with dri3

While Keith's patch does work on the overall issue with libudev, we should not link the loader util for non dri3 builds.

Here is a trivial fix that will resolve the problem. Thanks to Benjamin Bellec for the bisection.

Forgot to update the status

(In reply to comment #18)
> Created attachment 92554 [details] [review] [review]
> glx: link loader when building with dri3
> 
> While Keith's patch does work on the overall issue with libudev, we should
> not link the loader util for non dri3 builds.
> 
> Here is a trivial fix that will resolve the problem. Thanks to Benjamin
> Bellec for the bisection.

I confirm that the patch works.

(In reply to comment #20)
> (In reply to comment #18)
> > Created attachment 92554 [details] [review] [review] [review]
> > glx: link loader when building with dri3
> > 
> > While Keith's patch does work on the overall issue with libudev, we should
> > not link the loader util for non dri3 builds.
> > 
> > Here is a trivial fix that will resolve the problem. Thanks to Benjamin
> > Bellec for the bisection.
> 
> I confirm that the patch works.

Thanks again for the bisect. Pushed to master.