It builds fine but fails to start with NVIDIA GPUs. % yuzu Unhandled SIGSEGV at rip 0x0000080398a5a8 The same package works fine with AMD and Intel GPUs.
Which renderer: OpenGL or Vulkan or both? Probably similar to bug 229832. Can you attach ~/.local/share/yuzu/log/yuzu_log.txt when it fails?
(In reply to Jan Beich from comment #1) > Which renderer: OpenGL or Vulkan or both? Probably similar to bug 229832. Both. > Can you attach ~/.local/share/yuzu/log/yuzu_log.txt when it fails? It cannot even create a log file. % yuzu Unhandled SIGSEGV at rip 0x00000801ff6578 Segmentation fault % ls -l ~/.local/share/yuzu/log/ total 0 I built it with '-O0 -g' but I got nothing useful. % lldb ./yuzu (lldb) target create "./yuzu" Current executable set to '/usr/obj/data/usr/ports/emulators/yuzu-qt5/work/.build/bin/yuzu' (x86_64). (lldb) run Process 62908 launched: '/usr/obj/data/usr/ports/emulators/yuzu-qt5/work/.build/bin/yuzu' (x86_64) Process 62908 stopped * thread #1, name = 'yuzu', stop reason = signal SIGSEGV: address access protected (fault address: 0x8045bc578) frame #0: 0x00000008045bc578 libcxxrt.so.1`vtable for __cxxabiv1::__si_class_type_info + 16 libcxxrt.so.1`vtable for __cxxabiv1::__si_class_type_info: -> 0x8045bc578 <+16>: shrb 0x142(%rdx) 0x8045bc57e <+22>: addb %al, (%rax) 0x8045bc580 <+24>: subb $0x0, 0x142(%rax) 0x8045bc587 <+31>: addb %ah, %al (lldb) bt * thread #1, name = 'yuzu', stop reason = signal SIGSEGV: address access protected (fault address: 0x8045bc578) * frame #0: 0x00000008045bc578 libcxxrt.so.1`vtable for __cxxabiv1::__si_class_type_info + 16 frame #1: 0x000000000142770a yuzu`__dynamic_cast + 106 frame #2: 0x00000008196340d9 libKF5ConfigCore.so.5`___lldb_unnamed_symbol121$$libKF5ConfigCore.so.5 + 73 frame #3: 0x000000081962df53 libKF5ConfigCore.so.5`KConfigGroup::KConfigGroup(KConfigBase*, char const*) + 115 frame #4: 0x000000081926e9ad libKF5ConfigWidgets.so.5`___lldb_unnamed_symbol48$$libKF5ConfigWidgets.so.5 + 109 frame #5: 0x0000000819270ce6 libKF5ConfigWidgets.so.5`KColorScheme::KColorScheme(QPalette::ColorGroup, KColorScheme::ColorSet, QExplicitlySharedDataPointer<KSharedConfig>) + 726 frame #6: 0x0000000819271860 libKF5ConfigWidgets.so.5`KColorScheme::createApplicationPalette(QExplicitlySharedDataPointer<KSharedConfig> const&) + 224 frame #7: 0x0000000816ac93d3 KDEPlasmaPlatformTheme.so`___lldb_unnamed_symbol118$$KDEPlasmaPlatformTheme.so + 947 frame #8: 0x0000000816ac8149 KDEPlasmaPlatformTheme.so`___lldb_unnamed_symbol111$$KDEPlasmaPlatformTheme.so + 5865 frame #9: 0x0000000816ac3364 KDEPlasmaPlatformTheme.so`___lldb_unnamed_symbol79$$KDEPlasmaPlatformTheme.so + 116 frame #10: 0x0000000816ad9e5b KDEPlasmaPlatformTheme.so`___lldb_unnamed_symbol432$$KDEPlasmaPlatformTheme.so + 27 frame #11: 0x000000080be8f363 libQt5Gui.so.5`QPlatformThemeFactory::create(QString const&, QString const&) + 451 frame #12: 0x000000080be9b26b libQt5Gui.so.5`QGuiApplicationPrivate::createPlatformIntegration() + 5723 frame #13: 0x000000080be9baf0 libQt5Gui.so.5`QGuiApplicationPrivate::createEventDispatcher() + 32 frame #14: 0x000000080c82f88c libQt5Core.so.5`QCoreApplicationPrivate::init() + 1484 frame #15: 0x000000080be95aca libQt5Gui.so.5`QGuiApplicationPrivate::init() + 42 frame #16: 0x000000080b8940de libQt5Widgets.so.5`QApplicationPrivate::init() + 14 frame #17: 0x0000000000631148 yuzu`main(argc=1, argv=0x00007fffffffd500) at main.cpp:3399:32 frame #18: 0x0000000000443c50 yuzu`_start + 240 (lldb) up 17 frame #17: 0x0000000000631148 yuzu`main(argc=1, argv=0x00007fffffffd500) at main.cpp:3399:32 3396 3397 // Enables the core to make the qt created contexts current on std::threads 3398 QCoreApplication::setAttribute(Qt::AA_DontCheckOpenGLContextThreadAffinity); -> 3399 QApplication app(argc, argv); 3400 3401 // Qt changes the locale and causes issues in float conversion using std::to_string() when 3402 // generating shaders
Does it crash *before* starting any game? If so KF5 (Plasma) symbols in the stacktrace look suspicious. Did you test Intel/AMD GPUs on the same (Plasma) configuration? Can you reproduce in a pristine jail after passing through X11 socket?
(In reply to Jan Beich from comment #3) > Does it crash *before* starting any game? If so KF5 (Plasma) symbols in the stacktrace look suspicious. Yes. Why didn't I think of that? It runs fine on MATE. :-) > Did you test Intel/AMD GPUs on the same (Plasma) configuration? > Can you reproduce in a pristine jail after passing through X11 socket? No, both were running on MATE. I am building x11/kde5 to make sure.
(In reply to Jung-uk Kim from comment #4) I finally finished building x11/kde5 on those two boxes. Both AMD and Intel GPUs show the exact same symptoms, i.e., SIGSEGV.
(In reply to Jung-uk Kim from comment #5) Hello, could you please try : unset XDG_CURRENT_DESKTOP;unset DESKTOP_SESSION;unset KDE_FULL_SESSION;yuzu
(In reply to Loic from comment #6) > Hello, could you please try : > unset XDG_CURRENT_DESKTOP;unset DESKTOP_SESSION;unset KDE_FULL_SESSION;yuzu DESKTOP_SESSION is not set for me. Unsetting both XDG_CURRENT_DESKTOP and KDE_FULL_SESSION from environment variables let me start yuzu normally. Thanks!
Likely regressed by ports 4021ff7b85d9 due to libstdc++. Current workaround is fragile: libstdc++ needs to be linked against libcxxrt[1] but this was never implemented in lang/gcc* ports. And upstream libc++ (15.0.0-git) still lacks many C++20 features required by yuzu[2]. Ideally, yuzu upstream would fix libc++ via macOS support[3]. As this is a major usability blocker I'll try applying comment 6 as a patch: unsetenv(3) around main(); sh(1) wrapper makes debugging harder. [1] https://wiki.freebsd.org/NewC++Stack#Mixing_Libraries_using_Libc.2B-.2B-_and_Libstdc.2B-.2B- [2] addressof, atomic_ref, jthread, stop_token, ranges (all_of, count_if, find_if, transform, etc) [3] https://github.com/yuzu-emu/yuzu/pull/4165#issuecomment-945014852
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=8240af3d530bd4210f7739b6303e663ca21a441d commit 8240af3d530bd4210f7739b6303e663ca21a441d Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2022-02-10 06:54:13 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2022-02-10 07:59:18 +0000 emulators/yuzu: unbreak under Plasma after 4021ff7b85d9 $ yuzu Unhandled SIGSEGV at rip 0x0000083a532c18 PR: 256914 Reported by: jkim Submitted by: Loic (based on) emulators/yuzu/Makefile | 1 + emulators/yuzu/files/patch-kde (new) | 71 ++++++++++++++++++++++++++++++++++++ 2 files changed, 72 insertions(+)
A commit in branch 2022Q1 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=b7d3f79bb0f00e2610414910e301c105fe0a5700 commit b7d3f79bb0f00e2610414910e301c105fe0a5700 Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2022-02-10 06:54:13 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2022-02-10 07:59:32 +0000 emulators/yuzu: unbreak under Plasma after 4021ff7b85d9 $ yuzu Unhandled SIGSEGV at rip 0x0000083a532c18 PR: 256914 Reported by: jkim Submitted by: Loic (based on) (cherry picked from commit 8240af3d530bd4210f7739b6303e663ca21a441d) emulators/yuzu/Makefile | 1 + emulators/yuzu/files/patch-kde (new) | 71 ++++++++++++++++++++++++++++++++++++ 2 files changed, 72 insertions(+)
Does yuzu >= s20220210 work fine under KDE now? I did test under KDE myself but very briefly and got a report over private mail that s20220210 is still broken (could be a pilot error, an unhandled case or different issue).
(In reply to Jan Beich from comment #11) I also used it briefly and it worked fine.
After ports 45279a785c71 the workaround (and GCC) is gone. Nowadays, yuzu also works on aarch64[1], under Wayland (qt*-wayland) and with Qt6 (yuzu-qt6 package). [1] Runtime untested and may require amdgpu unless panfrost supports modern OpenGL/Vulkan features. However, build on -CURRENT (unlike 13.1) recently broke per https://pkg-status.freebsd.org/ampere2/data/main-arm64-default/p7dda4a77b8bb_s3fe0cb6695/logs/errors/yuzu-s20221220.log