There was a bug in Gentoo about this that was closed as WONTFIX:

https://bugs.gentoo.org/616402

Then I hit it today in pulseaudio. I attached gdb and got the following:

Thread 3 "Civ5XP" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xf40a9b40 (LWP 20552)]
0xec8bd9e5 in pa_smoother_new (adjust_time=1000000, history_time=5000000, monotonic=true, smoothing=true, min_history=4, time_offset=31853400925, paused=true) at /usr/src/debug/media-sound/pulseaudio-13.0/pulseaudio-13.0/src/pulsecore/time-smoother.c:102
102         pa_assert(adjust_time > 0);
(gdb) bt
#0  0xec8bd9e5 in pa_smoother_new (adjust_time=1000000, history_time=5000000, monotonic=true, smoothing=true, min_history=4, time_offset=31853400925, paused=true) at /usr/src/debug/media-sound/pulseaudio-13.0/pulseaudio-13.0/src/pulsecore/time-smoother.c:102
#1  0xf34d3db2 in create_stream (direction=PA_STREAM_PLAYBACK, s=0xebbf26c0, dev=0xebbf2380 "alsa_output.pci-0000_0b_00.1.hdmi-stereo-extra2", attr=0xebd06d60, flags=<optimized out>, volume=0x0, sync_stream=0x0) at /usr/src/debug/media-sound/pulseaudio-13.0/pulseaudio-13.0/src/pulse/stream.c:1257
#2  0xf77d109b in ?? () from ./libopenal.so.1
#3  0xf77d132c in ?? () from ./libopenal.so.1
#4  0xf77a89a3 in alcCreateContext () from ./libopenal.so.1
#5  0x09126f4a in YUV12 ()
#6  0x091264a2 in YUV12 ()
#7  0x09113bee in check_for_pending_io ()
#8  0x09114188 in BinkOpen ()
#9  0x085f7553 in ASL::PlayBinkMovieGL(char const*, float, unsigned int, unsigned int, bool*) ()
#10 0x0884c26c in PlayMovieState::Begin() ()
#11 0x086e0fc3 in Civ5App::PlayOpeningMovie() ()
#12 0x086e1c46 in Civ5App::Init(char const*) ()
#13 0x0865b3ed in WinMain ()
#14 0x085f5487 in ?? ()
#15 0x085d8e3e in ThreadHANDLE::ThreadProc(void*) ()
#16 0xf7b21204 in start_thread (arg=<optimized out>) at pthread_create.c:479
#17 0xf7965a26 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:108
(gdb) disassemble 
Dump of assembler code for function pa_smoother_new:
   0xec8bd9b0 <+0>:     push   %ebp
   0xec8bd9b1 <+1>:     push   %edi
   0xec8bd9b2 <+2>:     push   %esi
   0xec8bd9b3 <+3>:     push   %ebx
   0xec8bd9b4 <+4>:     call   0xec880f10 <__x86.get_pc_thunk.bx>
   0xec8bd9b9 <+9>:     add    $0x40647,%ebx
   0xec8bd9bf <+15>:    sub    $0x3c,%esp
   0xec8bd9c2 <+18>:    mov    0x58(%esp),%edi
   0xec8bd9c6 <+22>:    mov    0x50(%esp),%eax
   0xec8bd9ca <+26>:    mov    0x54(%esp),%edx
   0xec8bd9ce <+30>:    mov    0x6c(%esp),%esi
   0xec8bd9d2 <+34>:    mov    %edi,0x10(%esp)
   0xec8bd9d6 <+38>:    mov    0x60(%esp),%edi
   0xec8bd9da <+42>:    mov    %eax,(%esp)
   0xec8bd9dd <+45>:    mov    0x5c(%esp),%ebp
   0xec8bd9e1 <+49>:    mov    %edx,0x4(%esp)
=> 0xec8bd9e5 <+53>:    movdqa (%esp),%xmm0

That is a SSE2 instruction. After consulting with others, including Matt Turner of upstream Mesa at Intel, I found that this is caused by this bug against GCC that affects 32-bit software such as Civilization V:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838

The consequence is that whenever it calls into system library code (like pulseaudio) that was built with SSE2 instructions, there is a risk of a segfault from the call being misaligned. There are two ways of recompiling Civilization V to fix this:

1. Add `-march=nocona` to CFLAGS/CXXFLAGS, recompile and raise the minimum CPU version to match steam:

https://github.com/ValveSoftware/steam-for-linux

2. Add `-mpreferred-stack-boundary=4` to CFLAGS and CXXFLAGS and recompile:

https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html#index-mstackrealign

This should be done on all 32-bit software that Aspyr ships, not just Civilization V. Civilization V was just the lucky piece of software that caused me to observe this issue.