|
Bugzilla – Full Text Bug Listing |
| Summary: | libc: Portal and Civilization 5 segfault | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Carmen Bianca Bakker <carmen> |
| Component: | Basesystem | Assignee: | Richard Biener <rguenther> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | bwiedemann, carmen, coolo, forgotten_n8MvQUNHmg, jon, matz, okurz, rguenther, rombert, schwab, simon.herrmann, w01dnick |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | Civilization 5 not starting on Leap 42.2 | ||
|
Description
Carmen Bianca Bakker
2017-07-16 21:09:52 UTC
The backtrace for Portal: Thread 1 "hl2_linux" received signal SIGSEGV, Segmentation fault. 0xf7edd703 in __strpbrk_sse42 () from /lib/libc.so.6 (gdb) bt #0 0xf7edd703 in __strpbrk_sse42 () from /lib/libc.so.6 #1 0xf5c6496e in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #2 0xf5c43308 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #3 0xf5c43754 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #4 0xf5c2fe07 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #5 0xf5c3008a in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #6 0xf5c30ad9 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #7 0xf5c31648 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #8 0xf5c23589 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #9 0xf5c7250c in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #10 0xf5c770e8 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #11 0xf5c298e4 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #12 0xf5c3c866 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #13 0xf5c40a39 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #14 0xf5c3b18f in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/filesystem_stdio.so #15 0xf3bdfa9f in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #16 0xf3be1204 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #17 0xf3be091a in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #18 0xf3beab41 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #19 0xf3beacb3 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #20 0x0b52780b in ?? () #21 0x0b5281b5 in ?? () #22 0xe94f6a8a in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/vaudio_miles.so #23 0xe94f6e63 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/vaudio_miles.so #24 0xe94f6f8c in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/vaudio_miles.so #25 0xf3beaac7 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #26 0xf3bead3c in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #27 0xf3bdd2e0 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #28 0xf3baeb3a in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #29 0xf3bbc83f in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #30 0xf3bbcca6 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #31 0xf3c556ab in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #32 0xf3c58d36 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #33 0xf3dc13ff in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #34 0xf3d7adae in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #35 0xf3d8229e in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #36 0xf3c55063 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #37 0xf3d1227a in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #38 0xf3d13d0e in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #39 0xf3d15658 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #40 0xf3d2d421 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #41 0xf3d2d66e in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #42 0xf3d2d779 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #43 0xf3e114e2 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #44 0xf3e0e2df in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #45 0xf3e0e3ed in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #46 0xf3e631e0 in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #47 0xf3e0f44f in ?? () from /home/carmen/.local/share/Steam/steamapps/common/Portal/bin/engine.so #48 0xf66abba0 in ?? () from bin/launcher.so #49 0xf66abba0 in ?? () from bin/launcher.so #50 0xf6693d95 in LauncherMain () from bin/launcher.so #51 0x08048504 in main () Not sure what to make out of it, but indeed something is fishy - to evaluate the workaround done for arch, reassigning to andreas *** Bug 1048495 has been marked as a duplicate of this bug. *** A better workaround, not pessimizing programs following the ABI, is to force glibc to use the "default" non-SSE ifunc for all routines where that exists. I'm sure there's a way to do that. Andreas? To show it's affecting oS components too, here's a konqueror crash. Thread 1 (Thread 0x7f8b6fbf7740 (LWP 8491)): [KCrash Handler] #6 0x00007f8b6dd0f376 in __strcmp_ssse3 () at /lib64/libc.so.6 #7 0x00007f8b39b38098 in () at /usr/lib64/libQt5WebKit.so.5 #8 0x00007f8b39b381fb in WTF::Collator::collate(char16_t const*, unsigned long, char16_t const*, unsigned long) const () at /usr/lib64/libQt5WebKit.so.5 #9 0x00007f8b38a0f325 in () at /usr/lib64/libQt5WebKit.so.5 #10 0x00007f8b3744e072 in xsltForEach () at /usr/lib64/libxslt.so.1 Has anyone seen a GCC upstream report for this? I can't find it on https://gcc.gnu.org and it's pretty major if it's all AMD CPUs suffering. (In reply to Jon Brightwell from comment #5) > To show it's affecting oS components too, here's a konqueror crash. > > Thread 1 (Thread 0x7f8b6fbf7740 (LWP 8491)): > [KCrash Handler] > #6 0x00007f8b6dd0f376 in __strcmp_ssse3 () at /lib64/libc.so.6 > #7 0x00007f8b39b38098 in () at /usr/lib64/libQt5WebKit.so.5 > #8 0x00007f8b39b381fb in WTF::Collator::collate(char16_t const*, unsigned > long, char16_t const*, unsigned long) const () at > /usr/lib64/libQt5WebKit.so.5 > #9 0x00007f8b38a0f325 in () at /usr/lib64/libQt5WebKit.so.5 > #10 0x00007f8b3744e072 in xsltForEach () at /usr/lib64/libxslt.so.1 That just means that there's likely a bug in libQt5WebKit or libxslt. You can use gdb to see where in the callstack the outgoing stack is not aligned to 16 bytes according to the ABI requirements. A core file would also allow analysis with respect to this. I maybe reading it wrong but rsi isn't 16b aligned │0x7ffff785b360 <__strcmp_ssse3> mov %esi,%ecx │0x7ffff785b362 <__strcmp_ssse3+2> mov %edi,%eax │0x7ffff785b364 <__strcmp_ssse3+4> and $0x3f,%rcx │0x7ffff785b368 <__strcmp_ssse3+8> and $0x3f,%rax │0x7ffff785b36c <__strcmp_ssse3+12> cmp $0x30,%ecx │0x7ffff785b36f <__strcmp_ssse3+15> ja 0x7ffff785b3b0 <__strcmp_ssse3+80> │0x7ffff785b371 <__strcmp_ssse3+17> cmp $0x30,%eax │0x7ffff785b374 <__strcmp_ssse3+20> ja 0x7ffff785b3b0 <__strcmp_ssse3+80> b+>│0x7ffff785b376 <__strcmp_ssse3+22> movlpd (%rdi),%xmm1 │0x7ffff785b37a <__strcmp_ssse3+26> movlpd (%rsi),%xmm2 │0x7ffff785b37e <__strcmp_ssse3+30> movhpd 0x8(%rdi),%xmm1 │0x7ffff785b383 <__strcmp_ssse3+35> movhpd 0x8(%rsi),%xmm2 │0x7ffff785b388 <__strcmp_ssse3+40> pxor %xmm0,%xmm0 rax 0x0 0 rbx 0x7fffffffb5d0 140737488336336 rcx 0x0 0 rdx 0x7fffffffb46c 140737488335980 rsi 0x555556c12b40 93825016081216 rdi 0x0 0 rbp 0x7fffffffb46c 0x7fffffffb46c rsp 0x7fffffffb458 0x7fffffffb458 r8 0x5555569b0550 93825013581136 r9 0x7fffec1e12b8 140737154781880 r10 0x848 2120 r11 0x7ffff785b360 140737346122592 r12 0x7fffbe81ddc0 140736389569984 r13 0x0 0 r14 0xffffffff 4294967295 r15 0x7fffffffb668 140737488336488 rip 0x7ffff785b376 0x7ffff785b376 <__strcmp_ssse3+22> eflags 0x10283 [ CF SF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (In reply to Jon Brightwell from comment #8) > I maybe reading it wrong but rsi isn't 16b aligned > > │0x7ffff785b360 <__strcmp_ssse3> mov %esi,%ecx > > │0x7ffff785b362 <__strcmp_ssse3+2> mov %edi,%eax > > │0x7ffff785b364 <__strcmp_ssse3+4> and $0x3f,%rcx > > │0x7ffff785b368 <__strcmp_ssse3+8> and $0x3f,%rax > > │0x7ffff785b36c <__strcmp_ssse3+12> cmp $0x30,%ecx > > │0x7ffff785b36f <__strcmp_ssse3+15> ja 0x7ffff785b3b0 > <__strcmp_ssse3+80> > > │0x7ffff785b371 <__strcmp_ssse3+17> cmp $0x30,%eax > > │0x7ffff785b374 <__strcmp_ssse3+20> ja 0x7ffff785b3b0 > <__strcmp_ssse3+80> > > b+>│0x7ffff785b376 <__strcmp_ssse3+22> movlpd (%rdi),%xmm1 > > │0x7ffff785b37a <__strcmp_ssse3+26> movlpd (%rsi),%xmm2 > > │0x7ffff785b37e <__strcmp_ssse3+30> movhpd 0x8(%rdi),%xmm1 > > │0x7ffff785b383 <__strcmp_ssse3+35> movhpd 0x8(%rsi),%xmm2 > > │0x7ffff785b388 <__strcmp_ssse3+40> pxor %xmm0,%xmm0 > > rax 0x0 0 > rbx 0x7fffffffb5d0 140737488336336 > rcx 0x0 0 > rdx 0x7fffffffb46c 140737488335980 > rsi 0x555556c12b40 93825016081216 > rdi 0x0 0 > rbp 0x7fffffffb46c 0x7fffffffb46c > rsp 0x7fffffffb458 0x7fffffffb458 > r8 0x5555569b0550 93825013581136 > r9 0x7fffec1e12b8 140737154781880 > r10 0x848 2120 > r11 0x7ffff785b360 140737346122592 > r12 0x7fffbe81ddc0 140736389569984 > r13 0x0 0 > r14 0xffffffff 4294967295 > r15 0x7fffffffb668 140737488336488 > rip 0x7ffff785b376 0x7ffff785b376 <__strcmp_ssse3+22> > eflags 0x10283 [ CF SF IF RF ] > cs 0x33 51 > ss 0x2b 43 > ds 0x0 0 > es 0x0 0 > fs 0x0 0 > gs 0x0 0 rdi is 0 so this is a NULL pointer dereference rather than an alignment issue. Something does strcmp (..., NULL). Not backing into a corner here (honest) but surely it still would have crashed if the null hadn't caught it as the next line is misaligned and the pxor would have segfaulted. In any case, I'd submitted it to KDE for their perusal. (In reply to Jon Brightwell from comment #10) > Not backing into a corner here (honest) but surely it still would have > crashed if the null hadn't caught it as the next line is misaligned and the > pxor would have segfaulted. In any case, I'd submitted it to KDE for their > perusal. Not trying to be picky but mov[lh]pd do not have any alignment requirements and the pxor doesn't access memory but only register %xmm0 (actually clearing it). Thank you for clearing that up. Assembler isn't my strong point! (In reply to Jon Brightwell from comment #6) > Has anyone seen a GCC upstream report for this? I can't find it on > https://gcc.gnu.org and it's pretty major if it's all AMD CPUs suffering. I can open a bug report there if you want. Or someone else can in my stead, because I'm really not that great with C, assembly and the likes. It's not just AMD CPUs though. carmen@carmen-thinkpad:~> inxi -v1 System: Host: carmen-thinkpad Kernel: 4.11.8-1-default x86_64 (64 bit) Desktop: KDE Plasma 5.10.3 Distro: openSUSE Tumbleweed CPU: Dual core Intel Core i5-7200U (-HT-MCP-) speed/max: 1264/3100 MHz Graphics: Card: Intel Device 5916 Display Server: X.Org 1.19.3 drivers: modesetting (unloaded: fbdev,vesa) Resolution: 1920x1080@60.03hz GLX Renderer: Mesa DRI Intel HD Graphics 620 (Kaby Lake GT2) GLX Version: 3.0 Mesa 17.1.4 Drives: HDD Total Size: NA (-) Info: Processes: 240 Uptime: 0:12 Memory: 1646.8/7878.9MB Client: Shell (bash) inxi: 2.3.8 Please somebody provide a coredump for CIV5 and/or Portal segfaulting (or provide some context like disassembly at the faulting point). Opening a GCC bugreport upstream doesn't help -- this likely isn't a GCC nor a GLIBC bug. Borderlands pre
#0 0xf7a247c3 in __strspn_sse42 () from /lib/libc.so.6
#1 0xeddaa5a6 in pa_config_parse () from /usr/lib/pulseaudio/libpulsecommon-10.0.so
#2 0xedd9be9b in pa_client_conf_load () from /usr/lib/pulseaudio/libpulsecommon-10.0.so
#3 0xede27264 in pa_context_new_with_proplist () from /usr/lib/libpulse.so.0
│0xf7a247b0 <__strspn_sse42+48> movdqu -0x5a664(%edi,%ebx,1),%xmm3
│0xf7a247b9 <__strspn_sse42+57> mov %esi,%ebp
│0xf7a247bb <__strspn_sse42+59> mov $0x10,%eax
│0xf7a247c0 <__strspn_sse42+64> and $0xfffffff0,%ebp
>│0xf7a247c3 <__strspn_sse42+67> movaps %xmm3,(%esp)
│0xf7a247c7 <__strspn_sse42+71> movdqa 0x0(%ebp),%xmm0
│0xf7a247cc <__strspn_sse42+76> pshufb (%esp),%xmm0
│0xf7a247d2 <__strspn_sse42+82> pcmpistri $0x3a,%xmm0,%xmm0
eax 0x10 16
ecx 0xa 10
edx 0xffff4128 -48856
ebx 0xf7a98000 -139886592
esp 0xffff4094 0xffff4094
ebp 0xedde52c0 0xedde52c0
esi 0xedde52cd -304196915
edi 0xd 13
eip 0xf7a247c3 0xf7a247c3 <__strspn_sse42+67>
eflags 0x210286 [ PF SF IF RF ID ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x63 99
mxcsr 0x1fbf [ IE DE ZE OE UE PE IM DM ZM OM UM PM ]
ymm0 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x8000000000000000, 0x0, 0x0, 0x0}, v32_int8 = {0x73, 0x65, 0x2f, 0x63, 0x6c, 0x69, 0x65, 0x6e, 0x0 <repeats 24 times>}, v16_int16 = {0x6573, 0x632f, 0x696c, 0x6e65, 0x0 <repeats 12 times>}, v8_int32 = {0x632f6573, 0x6e65696c, 0x0,
0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x6e65696c632f6573, 0x0, 0x0, 0x0}, v2_int128 = {0x00000000000000006e65696c632f6573, 0x00000000000000000000000000000000}}
ymm1 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0 <repeats 32 times>}, v16_int16 = {0x0 <repeats 16 times>}, v8_int32 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x0, 0x0, 0x0, 0x0}, v2_int128 = {0x00000000000000000000000000000000,
0x00000000000000000000000000000000}}
ymm2 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x0, 0x0, 0x0, 0x0}, v32_int8 = {0x0 <repeats 32 times>}, v16_int16 = {0x0 <repeats 16 times>}, v8_int32 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0x0, 0x0, 0x0, 0x0}, v2_int128 = {0x00000000000000000000000000000000,
0x00000000000000000000000000000000}}
ymm3 {v8_float = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_double = {0x8000000000000000, 0x8000000000000000, 0x0, 0x0}, v32_int8 = {0xd, 0xe, 0xf, 0xff <repeats 13 times>, 0x0 <repeats 16 times>}, v16_int16 = {0xe0d, 0xff0f, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0}, v8_int32 = {0xff0f0e0d, 0xffffffff, 0xffffffff, 0xffffffff, 0x0, 0x0, 0x0, 0x0}, v4_int64 = {0xffffffffff0f0e0d, 0xffffffffffffffff, 0x0, 0x0}, v2_int128 = {0xffffffffffffffffffffffffff0f0e0d, 0x00000000000000000000000000000000}}
As was my guess, this is unaligned stack. Not sure why __strspn_sse42 needs to spill, but ... (In reply to Richard Biener from comment #16) > As was my guess, this is unaligned stack. Not sure why __strspn_sse42 needs > to spill, but ... strspn is implemented as C code, so the compiler spills. Jon, if you want to dig further, you can help us in determining which routines has (invalidly) misaligned the stack pointer. So the __strspn_sse42 has an %esp which doesn't have zero as last digit (i.e. it's not 16-byte aligned). Go upward the call stack and for each frame upwards print $esp in hex. So repeat the following commands and give us the output here: (gdb) p/x $esp (gdb) up (until you reach a frame where 'up' doesn't go further up) Thread 1 "BorderlandsPreS" received signal SIGSEGV, Segmentation fault. 0xf7a247c3 in __strspn_sse42 () from /lib/libc.so.6 $1 = 0xffff4094 #1 0xeddaa5a6 in pa_config_parse () from /usr/lib/pulseaudio/libpulsecommon-10.0.so $2 = 0xffff40c4 #2 0xedd9be9b in pa_client_conf_load () from /usr/lib/pulseaudio/libpulsecommon-10.0.so $3 = 0xffff5154 #3 0xede27264 in pa_context_new_with_proplist () from /usr/lib/libpulse.so.0 $4 = 0xffff52a4 #4 0xede273ce in pa_context_new () from /usr/lib/libpulse.so.0 $5 = 0xffff52e4 #5 0xd6845d62 in pulse_new () from /usr/lib/alsa-lib/libasound_module_pcm_pulse.so $6 = 0xffff5304 #6 0xd684578d in _snd_pcm_pulse_open () from /usr/lib/alsa-lib/libasound_module_pcm_pulse.so $7 = 0xffff7344 #7 0xf7583d1c in ?? () from /usr/lib/libasound.so.2 $8 = 0xffff73a4 #8 0xf7584234 in ?? () from /usr/lib/libasound.so.2 $9 = 0xffff7434 #9 0xf7586f6b in snd_pcm_open () from /usr/lib/libasound.so.2 $10 = 0xffff7484 #10 0xf74839a9 in ?? () from /usr/lib/libopenal.so.1 $11 = 0xffff74c4 #11 0xf7456e01 in alcOpenDevice () from /usr/lib/libopenal.so.1 $12 = 0xffff7504 #12 0x09482284 in ?? () $13 = 0xffff7554 #13 0x094817f2 in ?? () $14 = 0xffff75c4 #14 0x098f7b0e in ?? () $15 = 0xffff7604 #15 0x098f8097 in ?? () $16 = 0xffff7e1c #16 0x08226f55 in ?? () $17 = 0xffff7e50 #17 0x0822728c in ?? () $18 = 0xffff7eb0 #18 0x08225bff in ?? () $19 = 0xffff7fe0 #19 0x08225815 in ?? () $20 = 0xffff8030 #20 0x08226478 in ?? () $21 = 0xffff8230 #21 0x086a56e5 in ?? () $22 = 0xffff8260 #22 0x08cb4ef9 in ?? () $23 = 0xffffc740 #23 0x08ffefa0 in ?? () $24 = 0xffffc820 #24 0x08ff861d in ?? () $25 = 0xffffc910 #25 0x08ff87f7 in ?? () $26 = 0xffffc920 #26 0x08ff8a24 in ?? () $27 = 0xffffc960 #27 0x093810ee in ?? () $28 = 0xffffc980 #28 0x080e883b in ?? () $29 = 0xffffcdd0 #29 0xf78f32c3 in __libc_start_main () from /lib/libc.so.6 $30 = 0xffffcdf0 #30 0x097e321d in ?? () $31 = 0xffffce60 Initial frame selected; you cannot go up. $32 = 0xffffce60 You're going to make me redo that with debug symbols aren't you? :D Definitely not a glibc bug. (In reply to Jon Brightwell from comment #18) > Thread 1 "BorderlandsPreS" received signal SIGSEGV, Segmentation fault. > ... > You're going to make me redo that with debug symbols aren't you? :D That would be ideal :) But the command sequence from comment #17 would be more important (if, OTOH, you can install the debug symbols before doing this, that would be best). (gdb) p/x $esp $14 = 0xffff75c4 (gdb) up #14 0x098f7b0e in ?? () (gdb) p/x $esp $15 = 0xffff7604 (gdb) up #15 0x098f8097 in ?? () (gdb) p/x $esp $16 = 0xffff7e1c (gdb) up #16 0x08226f55 in ?? () (gdb) p/x $esp $17 = 0xffff7e50 (gdb) up #17 0x0822728c in ?? () Is there any specific way to know which debug symbol to load for that, as gdb is giving 30+. (or is the a quick way to do it other than copy paste the zypper commands from gdb output?) Of course this is closed source program so we could be in that. (In reply to Jon Brightwell from comment #21) > #15 0x098f8097 in ?? () > (gdb) p/x $esp > $16 = 0xffff7e1c > (gdb) up > #16 0x08226f55 in ?? () > (gdb) p/x $esp > $17 = 0xffff7e50 Ah, rats! Instruction pointers slightly above 0x08000000 are the adress range of normal executables on i586. So yeah, it's the program itself which misaligns stack (i.e. no hope for debuginfos). They would have to fix the program :-/ That's of course unlikely to happen. We aren't going to compile the normal glibc with stack realignment. That would pessimize all non-buggy programs. So the only other work around would be something like suggested in comment #4. Very unfortunately the glibc facility to select functions based on CPU features hasn't been updated to make use of the tunables framework, so it can't be influenced from the outside (via environment for instance). So even that work-around isn't possible. Until that has happened you'd have to use a private glibc build. I've put in a ticket to Aspyr. Perhaps we can provide a -mstackrealign glibc build for steam users? (In reply to Stephan Kulow from comment #24) > Perhaps we can provide a -mstackrealign glibc build for steam users? We can also figure out why GCC spills at all and/or add -mstackrealign (or -mincoming-stack-boundary=2) to a selected set of source files only (sysdeps/x86_64/multiarch/strspn-c.c and sysdeps/x86_64/multiarch/strpbrk-c.c). Note with a plain ./configure of glibc head and GCC 7.1 I can't see the spills we see. So we must add some configury that confuses the compiler here? > objdump --disassemble ./string/strspn-c.os | grep '(r[sb]p' > objdump --disassemble ./string/strspn-c.o | grep '(r[sb]p' maybe somehow things improved in HEAD compared to 2.25 whcih is in factory? Ah, it's the 32bit libc... unfortunately "cross" building with -m32 isn't too easy. OTOH building the 32bit glibc with -mstackrealign might not be too bad (the 42.2 32bit glibc doesn't spill though, so it looks like a compiler regression). Preprocessed source would be interesting. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81481 for the missed optimization in GCC 7. I spoke to Jan over at Arch about this and they pointed me at this OLD gcc bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 Not sure if the same but has some striking similarities. (In reply to Jon Brightwell from comment #28) > I spoke to Jan over at Arch about this and they pointed me at this OLD gcc > bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838 Not sure if the same > but has some striking similarities. It's about the same issue, the "old" ABI maintaining 4 byte stack alignment and the Linux/x86 ABI maintaining 16 byte stack alignment. It points out __attribute__((force_align_arg_pointer)) which we can annotate affected functions in 32bit glibc with. Note that this is still an application bug not adhering to the Linux/x86 ABI. It is also a missed optimization in GCC 7 to spill in those routines, tracked by the bug I opened. Created attachment 733722 [details]
Civilization 5 not starting on Leap 42.2
You mentioned Tumbleweed but Civilization also does not run on Leap 42.2. Perhaps this terminal output can help find the causes.
Getting the libc bug on AMD FX-8350 and Ryzen 1800X when trying to run Borderlands TPS. GDB output Ryzen 1800X: [gdb BTPS](https://pastebin.com/WcHp2s6t) [bt full](https://pastebin.com/nPiQzG0P) GDB output FX-8350 [gdb BTPS](https://pastebin.com/kiKjpT5f) [bt full](https://pastebin.com/cYkH3yu8) Is this still present with 7.2? I see the gcc bug entry hasn't changed but I was wondering if it was worth retesting. (In reply to Jon Brightwell from comment #32) > Is this still present with 7.2? I see the gcc bug entry hasn't changed but I > was wondering if it was worth retesting. Yes, the issue is still present. Still present. Checked on Borderlands 2 and Borderlands: The Pre-Sequel. Upstream now has a fix for the missed-optimization (unfortunately a few days too late for the latest gcc7 update in Tumbleweed...). I've staged it in devel:gcc now. I've also branched glibc off to home:rguenther:branches:Base:System which is building against devel:gcc so after gcc7 rebuilt there glibc should rebuild itself there and if you are brave you might want to test this glibc whether it fixes the problem for real. It's published now in home:rguenther:branches:Base:System, ready for testing. This is an autogenerated message for OBS integration: This bug (1048861) was mentioned in https://build.opensuse.org/request/show/531550 Factory / gcc7 Borderlands 2 and The Pre-Sequel start fine with glibc-32bit from home:rguenther:branches:Base:System. glibc-32bit from https://build.opensuse.org/package/show/openSUSE:Factory:Staging:C/glibc.i686 also helps to make Civilization 5 work again. Civilization V runs on my tumbleweed installation already for quite some time now. Other people still have issues? Let's mark it fixed. SUSE-SU-2018:0053-1: An update that solves 29 vulnerabilities and has 57 fixes is now available. Category: security (moderate) Bug References: 1003846,1004995,1009966,1022404,1025282,1025891,1026567,1029907,1029908,1029909,1029995,1030623,1035386,1036619,1039099,1039276,1039513,1040800,1040968,1041090,1043059,1043590,1043883,1043966,1044016,1045472,1045522,1045732,1047178,1047233,1048605,1048861,1050152,1050258,1050487,1052503,1052507,1052509,1052511,1052514,1052518,1053137,1053347,1053595,1053671,1055446,1055641,1055825,1056058,1056312,1056381,1057007,1057139,1057144,1057149,1057188,1057634,1057721,1057724,1058480,1058695,1058783,1059050,1059065,1059075,1059292,1059723,1060599,1060621,1061241,1061384,1062561,1063249,1063269,1064571,1064999,1065363,1066242,1066371,1066500,1066611,1067891,1070878,1070958,1071905,1071906 CVE References: CVE-2014-3710,CVE-2014-8116,CVE-2014-8117,CVE-2014-9620,CVE-2014-9621,CVE-2014-9653,CVE-2017-12448,CVE-2017-12450,CVE-2017-12452,CVE-2017-12453,CVE-2017-12454,CVE-2017-12456,CVE-2017-12799,CVE-2017-12837,CVE-2017-12883,CVE-2017-13757,CVE-2017-14128,CVE-2017-14129,CVE-2017-14130,CVE-2017-14333,CVE-2017-14529,CVE-2017-14729,CVE-2017-14745,CVE-2017-14974,CVE-2017-3735,CVE-2017-3736,CVE-2017-3737,CVE-2017-3738,CVE-2017-6512 Sources used: SUSE CaaS Platform ALL (src): sles12-caasp-dex-image-2.0.0-3.3.11, sles12-dnsmasq-nanny-image-2.0.1-2.3.15, sles12-haproxy-image-2.0.1-2.3.16, sles12-kubedns-image-2.0.1-2.3.11, sles12-mariadb-image-2.0.1-2.3.15, sles12-openldap-image-2.0.0-2.3.11, sles12-pause-image-2.0.1-2.3.9, sles12-pv-recycler-node-image-2.0.1-2.3.10, sles12-salt-api-image-2.0.1-2.3.10, sles12-salt-master-image-2.0.1-2.3.10, sles12-salt-minion-image-2.0.1-2.3.14, sles12-sidecar-image-2.0.1-2.3.11, sles12-tiller-image-2.0.0-2.3.11, sles12-velum-image-2.0.1-2.3.13 |