Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Blacklist lutris #197

Closed
wants to merge 1 commit into from
Closed

Blacklist lutris #197

wants to merge 1 commit into from

Conversation

valters-tomsons
Copy link
Contributor

@valters-tomsons valters-tomsons commented Jun 2, 2020 •
edited
Loading

Setting MANGOHUD=1 globally causes lutris to segfault.
This PR adds lutris to blacklist.

Sometimes it doesn't segfault and for others it seems it never segfaults. We probably don't want MangoHud for lutris itself anyway.

@jackun
Copy link
Collaborator

jackun commented Jun 2, 2020

If setting MANGOHUD=1 globally causes lutris to segfault then there's something else funky going on

@flightlessmango
Copy link
Owner

I've been unable to reproduce this for some time now, would be great to get a gdb output of this segfault

@valters-tomsons
Copy link
Contributor Author 

> lldb python
(lldb) target create "python"
Current executable set to 'python' (x86_64).

> run /usr/bin/lutris
Process 224021 launched: '/usr/bin/python' (x86_64)
Process 224021 stopped and restarted: thread 1 received signal: SIGCHLD
Process 224021 stopped and restarted: thread 1 received signal: SIGCHLD
Process 224021 stopped and restarted: thread 1 received signal: SIGCHLD
Process 224021 stopped and restarted: thread 1 received signal: SIGCHLD
Process 224021 stopped and restarted: thread 1 received signal: SIGCHLD
2020-06-02 22:50:30,734: Running Lutris 0.5.6
2020-06-02 22:50:30,734: Using X.Org
2020-06-02 22:50:30,735: Running Mesa driver 20.1.0 on Radeon RX 590 Series (POLARIS10, DRM 3.36.0, 5.6.15-zen2-1-zen, LLVM 10.0.0) (0x67df)
2020-06-02 22:50:30,735: GPU: 1002:67DF 148C:2391 using amdgpu drivers
Process 224021 stopped
* thread #1, name = 'python', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x00007ffff7abedea libc.so.6`__GI___strlen_sse2 + 42
libc.so.6`__GI___strlen_sse2:
->  0x7ffff7abedea <+42>: movdqu (%rax), %xmm4
    0x7ffff7abedee <+46>: pcmpeqb %xmm0, %xmm4
    0x7ffff7abedf2 <+50>: pmovmskb %xmm4, %edx
    0x7ffff7abedf6 <+54>: testl  %edx, %edx

@flightlessmango
Copy link
Owner

The next thing he checks is vulkan support with vkquery, if that has any significance

@jackun
Copy link
Collaborator

jackun commented Jun 2, 2020

Probably issue #160 that manifest with sse2 and somehow magically works with avx 😕

@valters-tomsons
Copy link
Contributor Author

Yeah, my FX-8300 doesn't have AVX.

I don't have vkquery, but trying vulkaninfo also gives me a segfault with MANGOHUD=1.

(lldb) target create "vulkaninfo"
Current executable set to 'vulkaninfo' (x86_64).
(lldb) run
Process 98251 launched: '/usr/bin/vulkaninfo' (x86_64)
ERROR: [Loader Message] Code 0 : /usr/lib32/libvulkan_intel.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib32/libvulkan_radeon.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/mangohud/lib32/libMangoHud.so: wrong ELF class: ELFCLASS32
Process 98251 stopped
* thread #1, name = 'vulkaninfo', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x00007ffff7ad1dea libc.so.6`__GI___strlen_sse2 + 42
libc.so.6`__GI___strlen_sse2:
->  0x7ffff7ad1dea <+42>: movdqu (%rax), %xmm4
    0x7ffff7ad1dee <+46>: pcmpeqb %xmm0, %xmm4
    0x7ffff7ad1df2 <+50>: pmovmskb %xmm4, %edx
    0x7ffff7ad1df6 <+54>: testl  %edx, %edx

Probably related with the issue mentioned then.
Still, I see no harm in blacklisting lutris either way.

@jackun
Copy link
Collaborator

jackun commented Jun 3, 2020

Run a backtrace with bt in lldb

@adonishycm
Copy link

so I have a weird issue. I went in to do lldb with bt for you, and when I tested I saw that launching anything that would have been broken works. If you look at my example below. Running lutris outside of lldb segfaults with a conf file. running lutris from lldb works fine.

➜ lutris         
2020-06-04 16:36:24,683: Running Lutris 0.5.6
2020-06-04 16:36:24,683: Using NVIDIA drivers 440.82 for x86_64
2020-06-04 16:36:24,683: GPU: GeForce GTX 1080
2020-06-04 16:36:24,684: GPU: 10DE:1B80 1043:8593 using nvidia drivers
skipping config: /usr/bin/MangoHud.conf [ not found ]
skipping config: /home/adonis/.config/MangoHud/python3.8.conf [ not found ]
parsing config: /home/adonis/.config/MangoHud/MangoHud.conf [ ok ]
2020-06-04 16:36:24,790: Vulkan is supported
2020-06-04 16:36:24,791: Updating DXVK versions
[1]    244516 segmentation fault (core dumped)  lutris

~/.config/MangoHud 
➜ lldb
(lldb) target create "python"
Current executable set to 'python' (x86_64).
(lldb) run /usr/bin/lutris 
Process 244945 launched: '/usr/bin/python' (x86_64)
Process 244945 stopped and restarted: thread 1 received signal: SIGCHLD
Process 244945 stopped and restarted: thread 1 received signal: SIGCHLD
Process 244945 stopped and restarted: thread 1 received signal: SIGCHLD
Process 244945 stopped and restarted: thread 1 received signal: SIGCHLD
Process 244945 stopped and restarted: thread 1 received signal: SIGCHLD
2020-06-04 16:36:52,361: Running Lutris 0.5.6
2020-06-04 16:36:52,362: Using NVIDIA drivers 440.82 for x86_64
2020-06-04 16:36:52,362: GPU: GeForce GTX 1080
2020-06-04 16:36:52,363: GPU: 10DE:1B80 1043:8593 using nvidia drivers
skipping config: /usr/bin/MangoHud.conf [ not found ]
skipping config: /home/adonis/.config/MangoHud/python3.8.conf [ not found ]
parsing config: /home/adonis/.config/MangoHud/MangoHud.conf [ ok ]
2020-06-04 16:36:52,992: Vulkan is supported
2020-06-04 16:36:52,993: Updating DXVK versions
2020-06-04 16:36:56,816: Shutting down Lutris
Process 244945 exited with status = 0 (0x00000000)

@adonishycm
Copy link

before you guys merge this commit with the apps required to be blacklisted, can this be retooled a bit ?
If possible make it read from a file in ~/.config/MangoHud/blacklist.conf for example where we list all the exes that need to be blocked. That way a user can circumvent the issues he has without having to download source/patch/recompile or wait for the devs to do it.

@valters-tomsons
Copy link
Contributor Author

valters-tomsons commented Jun 4, 2020 •
edited
Loading

@jackun
lutris:

(lldb) bt
* thread #1, name = 'python', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
  * frame #0: 0x00007ffff7abedea libc.so.6`__GI___strlen_sse2 + 42
    frame #1: 0x00007fffec277561 libstdc++.so.6`std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(char const*) const [inlined] std::c
har_traits<char>::length(__s=0x0000000000000000) at char_traits.h:357:25
    frame #2: 0x00007fffec277558 libstdc++.so.6`std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(this="python3.8", __s=0x00000000000
00000) const at basic_string.tcc:1433
    frame #3: 0x00007fffdfe3fd02 libMangoHud.so`is_blacklisted() + 354
    frame #4: 0x00007fffdfe29f5f libMangoHud.so`find_ptr(char const*) + 111
    frame #5: 0x00007fffdfe36555 libMangoHud.so`overlay_GetInstanceProcAddr + 21
    frame #6: 0x00007fffee6eb57b libvulkan.so.1`___lldb_unnamed_symbol323$$libvulkan.so.1 + 683
    frame #7: 0x00007fffee6ef37e libvulkan.so.1`vkCreateInstance + 1022
    frame #8: 0x00007ffff6e86a8d libffi.so.7`___lldb_unnamed_symbol30$$libffi.so.7 + 85
    frame #9: 0x00007ffff6e8601b libffi.so.7`___lldb_unnamed_symbol27$$libffi.so.7 + 427
    frame #10: 0x00007ffff4029c79 _ctypes.cpython-38-x86_64-linux-gnu.so`___lldb_unnamed_symbol21$$_ctypes.cpython-38-x86_64-linux-gnu.so + 1216
    frame #11: 0x00007ffff40333ef _ctypes.cpython-38-x86_64-linux-gnu.so`___lldb_unnamed_symbol213$$_ctypes.cpython-38-x86_64-linux-gnu.so + 431
    frame #12: 0x00007ffff7d0e18c libpython3.8.so.1.0`_PyObject_MakeTpCall + 1116
    frame #13: 0x00007ffff7d09a78 libpython3.8.so.1.0`_PyEval_EvalFrameDefault + 20744
    frame #14: 0x00007ffff7d157e8 libpython3.8.so.1.0`_PyFunction_Vectorcall + 264
    frame #15: 0x00007ffff7d09635 libpython3.8.so.1.0`_PyEval_EvalFrameDefault + 19653
    frame #16: 0x00007ffff7d157e8 libpython3.8.so.1.0`_PyFunction_Vectorcall + 264
    frame #17: 0x00007ffff7d04d08 libpython3.8.so.1.0`_PyEval_EvalFrameDefault + 920
    frame #18: 0x00007ffff7d157e8 libpython3.8.so.1.0`_PyFunction_Vectorcall + 264
    frame #19: 0x00007ffff7d04d08 libpython3.8.so.1.0`_PyEval_EvalFrameDefault + 920
    frame #20: 0x00007ffff7d157e8 libpython3.8.so.1.0`_PyFunction_Vectorcall + 264
    frame #21: 0x00007ffff7d28dd2 libpython3.8.so.1.0`PyObject_Call + 530
    frame #22: 0x00007ffff70a6a9d _gi.cpython-38-x86_64-linux-gnu.so`___lldb_unnamed_symbol320$$_gi.cpython-38-x86_64-linux-gnu.so + 861
    frame #23: 0x00007ffff6e868c2 libffi.so.7`___lldb_unnamed_symbol29$$libffi.so.7 + 434
    frame #24: 0x00007ffff6e86c20 libffi.so.7`___lldb_unnamed_symbol32$$libffi.so.7 + 72
    frame #25: 0x00007ffff6cbcdc6 libgio-2.0.so.0`___lldb_unnamed_symbol631$$libgio-2.0.so.0 + 134
    frame #26: 0x00007ffff6ebb80a libgobject-2.0.so.0`g_signal_emit_valist + 4730
    frame #27: 0x00007ffff6ebb980 libgobject-2.0.so.0`g_signal_emit + 144
    frame #28: 0x00007ffff6d1a827 libgio-2.0.so.0`___lldb_unnamed_symbol1739$$libgio-2.0.so.0 + 311
    frame #29: 0x00007ffff6d1ba72 libgio-2.0.so.0`___lldb_unnamed_symbol1741$$libgio-2.0.so.0 + 578
    frame #30: 0x00007ffff6d1bc0a libgio-2.0.so.0`g_application_run + 314
    frame #31: 0x00007ffff6e86a8d libffi.so.7`___lldb_unnamed_symbol30$$libffi.so.7 + 85
    frame #32: 0x00007ffff6e8601b libffi.so.7`___lldb_unnamed_symbol27$$libffi.so.7 + 427
    frame #33: 0x00007ffff709d3a2 _gi.cpython-38-x86_64-linux-gnu.so`___lldb_unnamed_symbol121$$_gi.cpython-38-x86_64-linux-gnu.so + 1954
    frame #34: 0x00007ffff709c982 _gi.cpython-38-x86_64-linux-gnu.so`___lldb_unnamed_symbol118$$_gi.cpython-38-x86_64-linux-gnu.so + 82
    frame #35: 0x00007ffff7d28e6c libpython3.8.so.1.0`PyObject_Call + 684
    frame #36: 0x00007ffff7d06da5 libpython3.8.so.1.0`_PyEval_EvalFrameDefault + 9269
    frame #37: 0x00007ffff7d03654 libpython3.8.so.1.0`_PyEval_EvalCodeWithName + 772
    frame #38: 0x00007ffff7d1587d libpython3.8.so.1.0`_PyFunction_Vectorcall + 413
    frame #39: 0x00007ffff7d050d1 libpython3.8.so.1.0`_PyEval_EvalFrameDefault + 1889
    frame #40: 0x00007ffff7d03654 libpython3.8.so.1.0`_PyEval_EvalCodeWithName + 772
    frame #41: 0x00007ffff7db3b03 libpython3.8.so.1.0`PyEval_EvalCode + 35
    frame #42: 0x00007ffff7dbf248 libpython3.8.so.1.0`___lldb_unnamed_symbol4291$$libpython3.8.so.1.0 + 72
    frame #43: 0x00007ffff7db9483 libpython3.8.so.1.0`___lldb_unnamed_symbol4240$$libpython3.8.so.1.0 + 83
    frame #44: 0x00007ffff7c793f8 libpython3.8.so.1.0`PyRun_FileExFlags + 151
    frame #45: 0x00007ffff7c78e8a libpython3.8.so.1.0`PyRun_SimpleFileExFlags + 905
    frame #46: 0x00007ffff7dcc1e2 libpython3.8.so.1.0`Py_RunMain + 1282
    frame #47: 0x00007ffff7da83d9 libpython3.8.so.1.0`Py_BytesMain + 57
    frame #48: 0x00007ffff7a47002 libc.so.6`__libc_start_main + 242
    frame #49: 0x000055555555504e python`_start + 46

(lldb) target create "vulkaninfo"
Current executable set to 'vulkaninfo' (x86_64).
(lldb) run
Process 26080 launched: '/usr/bin/vulkaninfo' (x86_64)
ERROR: [Loader Message] Code 0 : /usr/lib32/libvulkan_intel.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib32/libvulkan_radeon.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/mangohud/lib32/libMangoHud.so: wrong ELF class: ELFCLASS32
Process 26080 stopped
* thread #1, name = 'vulkaninfo', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x00007ffff7ad1dea libc.so.6`__GI___strlen_sse2 + 42
libc.so.6`__GI___strlen_sse2:
->  0x7ffff7ad1dea <+42>: movdqu (%rax), %xmm4
    0x7ffff7ad1dee <+46>: pcmpeqb %xmm0, %xmm4
    0x7ffff7ad1df2 <+50>: pmovmskb %xmm4, %edx
    0x7ffff7ad1df6 <+54>: testl  %edx, %edx
(lldb) bt
* thread #1, name = 'vulkaninfo', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
  * frame #0: 0x00007ffff7ad1dea libc.so.6`__GI___strlen_sse2 + 42
    frame #1: 0x00007ffff7d56561 libstdc++.so.6`std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(char const*) const [inlined] std::char_traits<char>::length(__s=0x0000000000000000) at char_traits.h:357:25
    frame #2: 0x00007ffff7d56558 libstdc++.so.6`std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::compare(this="vulkaninfo", __s=0x0000000000000000) const at basic_string.tcc:1433
    frame #3: 0x00007fffed192d02 libMangoHud.so`is_blacklisted() + 354
    frame #4: 0x00007fffed17cf5f libMangoHud.so`find_ptr(char const*) + 111
    frame #5: 0x00007fffed189555 libMangoHud.so`overlay_GetInstanceProcAddr + 21
    frame #6: 0x00007ffff787e57b libvulkan.so`___lldb_unnamed_symbol323$$libvulkan.so + 683
    frame #7: 0x00007ffff788237e libvulkan.so`vkCreateInstance + 1022
    frame #8: 0x00005555555b49fb vulkaninfo`___lldb_unnamed_symbol514$$vulkaninfo + 2891
    frame #9: 0x0000555555562911 vulkaninfo`___lldb_unnamed_symbol196$$vulkaninfo + 433
    frame #10: 0x00007ffff7a5a002 libc.so.6`__libc_start_main + 242
    frame #11: 0x000055555556466e vulkaninfo`___lldb_unnamed_symbol198$$vulkaninfo + 46

@jackun
Copy link
Collaborator

jackun commented Jun 4, 2020 •
edited
Loading

@Faithlv does it help if you change const char* in std::array to std::string or std::array with std::vector even? Looks like off by one error but it shouldn't 🤔

@valters-tomsons
Copy link
Contributor Author

@jackun Yes! Changing const char* to std::string fixed crashing for both lutris and vulkaninfo. Both now work with MANGOHUD=1 and without adding them to blacklist.

@valters-tomsons
Copy link
Contributor Author

Closing because #204 solves the crash.

@valters-tomsons valters-tomsons mentioned this pull request Jun 8, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@valters-tomsons @jackun @flightlessmango @adonishycm