Arch Linux

Hm, I can confirm this. It crashes in libpulse attempting to parse the pulseaudio client.conf:

#0 0xf7192693 in __strspn_sse42 () from /usr/lib32/libc.so.6
No symbol table info available.
#1 0xecde77e4 in parse_line (state=0xffad98bc) at pulsecore/conf-parser.c:85
c = <optimized out>
#2 pa_config_parse (filename=0xf0dadf0 "/etc/pulse/client.conf", f=0x20f23728, t=0xffada944, proplist=0x0, use_dot_d=true, userdata=0x0) at pulsecore/conf-parser.c:202
r = -1
do_close = false
state = {filename = 0xf0dadf0 "/etc/pulse/client.conf", lineno = 1, section = 0x0, lvalue = 0x0, rvalue = 0x0, data = 0x0, userdata = 0x0, item_table = 0xffada944,
buf = "# This file is part of PulseAudio.\n", '\000' <repeats 4060 times>, proplist = 0x0, in_proplist = false}
__func__ = "pa_config_parse"
__PRETTY_FUNCTION__ = "pa_config_parse"
#3 0xecdd5bcb in pa_client_conf_load (c=0x20f235f0, load_from_x11=true, load_from_env=true) at pulse/client-conf.c:153
f = 0x20f23728
fn = 0xf0dadf0 "/etc/pulse/client.conf"
table = {{lvalue = 0xece2389c "daemon-binary", parse = 0xecde8420 <pa_config_parse_string>, data = 0x20f235f0, section = 0x0}, {lvalue = 0xece238aa "extra-arguments", parse = 0xecde8420 <pa_config_parse_string>,
data = 0x20f235f4, section = 0x0}, {lvalue = 0xece238ba "default-sink", parse = 0xecde8420 <pa_config_parse_string>, data = 0x20f235f8, section = 0x0}, {lvalue = 0xece238c7 "default-source",
parse = 0xecde8420 <pa_config_parse_string>, data = 0x20f235fc, section = 0x0}, {lvalue = 0xece238d6 "default-server", parse = 0xecde8420 <pa_config_parse_string>, data = 0x20f23600, section = 0x0}, {
lvalue = 0xece238e5 "default-dbus-server", parse = 0xecde8420 <pa_config_parse_string>, data = 0x20f23604, section = 0x0}, {lvalue = 0xece238f9 "autospawn", parse = 0xecde82a0 <pa_config_parse_bool>, data = 0x20f23718,
section = 0x0}, {lvalue = 0xece23903 "cookie-file", parse = 0xecde8420 <pa_config_parse_string>, data = 0x20f23714, section = 0x0}, {lvalue = 0xece2390f "disable-shm", parse = 0xecde82a0 <pa_config_parse_bool>,
data = 0x20f23719, section = 0x0}, {lvalue = 0xece2391b "enable-shm", parse = 0xecde8360 <pa_config_parse_not_bool>, data = 0x20f23719, section = 0x0}, {lvalue = 0xece23926 "enable-memfd",
parse = 0xecde8360 <pa_config_parse_not_bool>, data = 0x20f2371a, section = 0x0}, {lvalue = 0xece23933 "shm-size-bytes", parse = 0xecde81c0 <pa_config_parse_size>, data = 0x20f23720, section = 0x0}, {
lvalue = 0xece23942 "auto-connect-localhost", parse = 0xecde82a0 <pa_config_parse_bool>, data = 0x20f2371b, section = 0x0}, {lvalue = 0xece23959 "auto-connect-display", parse = 0xecde82a0 <pa_config_parse_bool>,
data = 0x20f2371c, section = 0x0}, {lvalue = 0x0, parse = 0x0, data = 0x0, section = 0x0}}
#4 0xece69fc2 in pa_context_new_with_proplist (mainloop=0x20c31c48, name=0xffadaae4 "Borderlands2", p=0x0) at pulse/context.c:171
type = <optimized out>
__func__ = "pa_context_new_with_proplist"
__PRETTY_FUNCTION__ = "pa_context_new_with_proplist"
#5 0xece6a12e in pa_context_new (mainloop=0x20c31c48, name=0xffadaae4 "Borderlands2") at pulse/context.c:103
No locals.
#6 0xf6d0a3dc in ?? () from /usr/lib32/libopenal.so.1
No symbol table info available.
#7 0xf6d0bd3d in ?? () from /usr/lib32/libopenal.so.1
No symbol table info available.
#8 0xf6cd93b9 in ?? () from /usr/lib32/libopenal.so.1
No symbol table info available.
#9 0xf7354525 in __pthread_once_slow () from /usr/lib32/libpthread.so.0
No symbol table info available.
#10 0xf6cda365 in alcOpenDevice () from /usr/lib32/libopenal.so.1
No symbol table info available.

It calls strspn(state->buf, " \t\n"). Since state->buf looks fine this is a bad strspn.

I'm experiencing a similar issue with Portal. The game crashes in `__strpbrk_sse42` during startup, before it can even reach the menu.

This bug might be related to GCC 7.1. I couldn't reproduce the issue with glibc 2.25-1 nor 2.25-2 after rebuilding them with `-march=native`, but with the defaults of `-march=x86-64 -mtune=generic`, the game crashes on both.

I've checked the flags enabled by `-march=native` on my ivy bridge system, then tested by elimination and found out that enabling `-mavx` is enough to get the game running. I have no idea why this would happen, especially considering the problematic functions seem to be SSE 4.2, not AVX, but can anyone else confirm this?

Investigated some more, looks like GCC replaces all SSE instructions with their AVX equivalents when -mavx is in use. strpbrk and strspn are internally the same function and are written in C using GCC's SIMD extensions. This is very likely a GCC bug as the current build in multilib using GCC 6.3 works fine.

It attempts a MOVAPS (aligned store) from XMM3 into the memory pointed to by ESP, but the stack pointer is not aligned to 16 bytes. The AVX version avoids using the stack.

Released 2.25-3 with -mstackrealign to work around it, but this costs performance. Still, better than nothing.